Кілька рад по автоматизації моніторингу ЦОД. Частина 1



Моніторинг інфраструктури дата-центру — непросте завдання. Часто для її спрощення використовується автоматизація. Ну а що ж відмінно, отримувати собі на монітор всі повідомлення системи моніторингу. Як ми вже писали, що автоматизація всього і вся — це непогано. Це досить складна, але розв'язувана задача. Навіщо її взагалі вирішувати, автоматизуючи виявлення нових пристроїв, з'єднань, програмного забезпечення, створюючи сценарії дій системи появу тригерів?

Все тому, що людина ледачий, автоматика в багатьох випадках буде працювати краще. Але і тут є проблеми. Здавалося б, що може статися після впровадження такої системи? Начебто основні проблеми вирішені, будь-яка проблема не залишиться непоміченою. Але насправді деякі важливі питання залишаються, найчастіше, невирішеними. Більше того, вони зустрічаються дуже часто. Мова йде про двох таких проблемах, і вони ми поговоримо в продовженні.

Проблема 1: повідомлення про помилку — це ще не все
Стратегією можна назвати пошук брокколі в магазинах і процес покупки. Тактикою в даному випадку можна назвати вміння умовити дітей з'їсти приготоване.
Томас ЛаРок, SolarWinds

Перш ніж заглиблюватися в автоматизацію, будь то автоматичне виявлення проблеми, відправка звіту або сценарій дій на випадок непередбаченої ситуації, необхідно вжити заходи щодо однієї критичної речі. Мова йде про так званому DPR циклі, який розшифровується, як Detection, Prevention, Response. Іншими словами, мова йде про процедуру виявлення проблеми, запобігання її появи і відповідних діях співробітників ЦОД у разі появи проблеми.

Зараз зупинимося на помилках і повідомленнях про їх появи. Скажімо, саппорт отримав таке повідомлення автоматичної системи попередження, відмінно. Тепер потрібно розібратися в тому, чому ця помилка виникла, а також знайти спосіб, що дозволяє запобігти в майбутньому її повторну появу.

У процесі створення служби автоматичних повідомлень про помилки потрібно також передбачити і те, що це тільки початок. Адже потрібно виконати ще й важку роботу з аналізу ситуації, для того, щоб знайти причину виникнення небажаної ситуації. Після цього потрібно створити додаткові перевірочні модулі, спрямовані на ідентифікацію вже трапилася ситуації. Може бути, ми і впевнені в тому, що вона вже не з'явиться, але всяке може бути.

Автоматична реакція на повідомлення системи попередження дозволяє трохи розслабитися, адже за все відповідає автоматика. Але інженери повинні все одно розбиратися в тому, чому проблема виникла. Автоматика, найчастіше, на це нездатна.



Проблема 2: розгортання системи автоматизації моніторингу
Мова йде про те, що перед впровадженням системи автоматизації необхідно мати план того, що повинна вміти така система. Її необхідно ретельно продумати, щоб потім не було проблем. Ну а в плані потрібно передбачити наступне:
  • Наявність вибірки тестових машин. Це можуть бути чисто «лабораторні» сервери, на яких буде відпрацьовуватися система автоматизації, або машини, які використовуються в ході роботи, але які по тій або іншій причині менш пріоритетними, ніж всі інші;
  • Не варто відпрацьовувати ситуації, доводячи роботу машини до критичної. Скажімо, для відпрацювання системи повідомлень про критичну навантаження на сервера не варто доводити завантаження ресурсів системи до 90%, вистачить і меншого рівня;
  • Якщо система підтримує логування, то варто включити цю функцію. У підсумку, якщо трапляється проблема, ви будете розуміти, що саме сталося і чому. Журнал подій повинен бути максимально детальним;
  • У деяких випадках не варто відправляти повідомлення про проблеми по e-mail. Все це провокує додаткові затримки в роботі. Уявіть собі, що в пошту прийшло 740 повідомлень, і з ними необхідно тепер розгрібати, відкриваючи кожне повідомлення по черзі. Краще всього зберігати повідомлення локально, одночасно виводячи на дисплей;
  • Результати тестування системи сповіщень варто обговорити з саппортом, можливо, представники команди підтримки порадять слушні речі;
  • Після того, як система відпрацьована в тестовому варіанті, варто її потихеньку вводити в роботу. Причому розгортати систему потрібно не відразу всю, а поетапно. Спочатку включити її для 10-20 систем. Потім оцінити результати. Потім розширити систему ще на 50 машин, і знову перевірити. Поетапне включення системи автоматизації повідомлень дозволить уникнути масштабних помилок при розгортанні такої системи відразу на 100% машин. В останньому випадку, якщо виникне проблема, це може позначитися на всьому дата-центру.
Якщо скористатися цими порадами, можна побачити недоліки системи автоматизації, і зрозуміти, як їх виправити до того, як трапиться масштабний збій. Для того, щоб при реалізації системи автоматизації використовувати дійсно актуальні інструменти, варто обговорювати з командою наступні етапи роботи. На що фахівці скаржаться найбільше? Це і потрібно вирішувати в першу чергу.

Якщо все вийде, то ви зможете позбавити себе і команду від постійно виникаючих і повторюваних ситуацій, на які доводиться витрачати свій час, якого, природно, завжди не вистачає. Те, що вказане в матеріалі — лише мала частина роботи з впровадження системи автоматизації моніторингу ЦОД. Частина вже була показана раніше, решту плануємо опублікувати найближчим часом.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.