Моніторинг інженерної інфраструктури в дата-центрі. Частина 1. Основні моменти

Статтю про пристрій моніторингу в дата-центрі ми обіцяли ще у вересні. Тема велика, однією статтею тут не обійтися, тому вирішили зробити серію постів. Почнемо з базових моментів, про які важливо пам'ятати при проектуванні та налаштування моніторингу. Потім докладно зупинимося на основних інженерних системах (енергопостачання та холодопостачання) і розповімо про інструменти для їх моніторингу.

У статтях будемо ділитися своїм досвідом, тим, що пробували і використовуємо самі у власних дата-центрах. Не претендуємо На повноту, зате все буде з життя, а не з підручника.

У коментарях можна спробувати вплинути на редакційну політику і запропонувати для розгляду цікаві саме для вас аспекти моніторингу.



З організаційними моментами начебто розібралися, приступимо до абетки моніторингу в редакції DataLine :). Отже, сьогодні мова піде про концептуальні речі, які потрібно враховувати на етапі проектування, впровадження та налаштування системи моніторингу. Сабж розглянемо на прикладі нашого моніторингу, побудованого на базі Nagios і Cacti.

Що таке моніторинг
У цій серії статей ми будемо говорити про «класичному» моніторинг, тобто без автоматизованого управління.

Моніторинг можна трактувати по-різному: як система і як процес. У нашому випадку це дві сторони однієї медалі – одне без іншого існувати не може.

Моніторинг як система допомагає безперервно збирати, зберігати та аналізувати параметри устаткування і систем. Він постачає дані, на основі яких інженер робить висновки про поточний стан і про можливе майбутнє поведінці спостережуваного об'єкта.

Система моніторингу дає лише вступну інформацію, далі справа за людьми і процесами. Чіткі регламенти в штатних і аварійних ситуаціях, вибудувана система оповіщення відповідальних осіб – все це перетворює моніторинг з простого збору даних корисний інструмент для управління інфраструктурою.

Коли потрібно зайнятися системою моніторингу
Тоді ж, коли і починаєте проектувати інженерну інфраструктуру. Якщо займатися моніторингом вже після запуску дата-центру, то якийсь час служба експлуатації буде працювати наосліп. Чергові інженери не зможуть відслідковувати помилки в роботі обладнання, пропустять перед аварійні ситуації. Єдиний доступний спосіб моніторингу в такій ситуації – це фізичний обхід всіх інженерних систем і ІТ-обладнання.

Приклад 1: дата-центр запустили в експлуатацію. Перші місяці зал був майже порожній і з трьох кондиціонерів працював тільки один. Із заповненням залу температура в залі зросла. Так як моніторингу немає, то службі експлуатації буде складно визначити момент, коли включити другий, а у випадку аварії – резервний.

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

Є гарний вислів: неможливо управляти тим, що не можна виміряти. Це як раз про експлуатацію інженерної інфраструктури без моніторингу. Продумуйте моніторинг заздалегідь.

За чим потрібно стежити
Моніторинг інженерної інфраструктури потрібно вести по можливості на трьох рівнях: автономні датчики, обладнання та системи в цілому.

Під автономними датчиками ми в першу чергу маємо на увазі датчики протікання, температурні датчики, датчики об'єму і руху.

  • датчики протікання потрібні завжди, особливо якщо в дата-центрі використовується система охолодження з рідким теплоносієм або фреонова з зволоженням. Розміщуємо їх під кожним кондиціонером, вузлом і краном трубопроводу, тобто в тих місцях, де може закапати.
  • температурні датчики встановлюємо у холодних і гарячих коридорах машинних залів, в приміщеннях з інженерною інфраструктурою (насосні, приміщення АКБ, ГРЩ і тощо).
  • датчики об'єму/руху, відкриття і закриття дверей стійок. На відміну від попередніх, вони опціональні. Їх можна використовувати в залах або для групи стійок, обгородженій парканом (cage).
Обладнання потрібно моніторити по можливості все: ДБЖ, ДГУ, кондиціонери, PDU, АВР, камери і ін. По кожному важливо отримувати наступну інформацію:

  • працює;
  • які помилки виникають в роботі;
  • значення окремих параметрів (напруга в ДБЖ, сила струму, рівень палива в баку ДДУ, температура на вході і виході кондиціонера, швидкість обертання вентилятора і тощо).
Стежити за кожною одиницею обладнання ізоляції недостатньо. Щоб розуміти загальну картину, відстежуйте системи цілком. Так ви зможете бачити взаємозв'язок обладнання єдиною ниткою, і вам буде легше зрозуміти, на якому етапі виникла несправність. Взаємозв'язки обладнання в системі можна візуалізувати за допомогою принципових схем.

Приклад 2: відключився розподільний щит в машинному залі. Якщо ми моніторимо обладнання окремо, то знадобиться час, щоб зрозуміти джерело поломки – щит або ІБП, від якого він харчується. Якщо ж у нас перед очима буде схема всієї системи, то ми швидко побачимо слабка ланка.


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

Документація з моніторингу
По мірі того, як визначаємося з об'єктами і параметрами моніторингу, складаємо документацію по системі. В ній фіксуємо:

  • список датчиків і обладнання на моніторингу;
  • місце їх установки;
  • записані параметри та конкретні значення;
  • схеми підключення;
  • порогові значення для повідомлень про аварійних ситуаціях
Це теж краще робити на етапі проектування, щоб у служби експлуатації була повна документація з самого початку і вони розуміли:

  • всі цікавлять об'єкти поставлені на моніторинг;
  • де шукати проблему в разі несправності самої системи моніторингу;
  • які порогові значення використовуються.
Без такої шпаргалки службі експлуатації доведеться дослідити систему моніторингу заново.

Незалежність і резервування системи моніторингу
Під моніторинг краще використовувати окреме серверне та мережеве обладнання з виділеним мережевим сегментом.

Сервери повинні бути зарезервовані так, щоб при виході з ладу одного з серверів моніторинг продовжив працювати на другому. Зовсім добре, якщо серверів кластера рознесені по різних машинним приміщенням. В одному з наступних постів докладно розглянемо пристрій і принцип роботи такого кластера.

Монітори, на які виводяться схеми, повідомлення, також повинні бути підключені до безперебійного харчування з резервом. По мережі також — мережеві розетки підключені до різних комутаторів. Так чергові інженери не залишаться наодинці згаслими екранами, коли в дата-центрі відбувається щось цікаве.

Єдиний центр моніторингу
Всю інформацію з датчиків, обладнання і систем потрібно зводити в єдиний інтерфейс і вибірково відображати на екранах в центрі моніторингу.
За всім цим господарством повинен слідкувати цілодобово хоча б один черговий інженер. Тут же всі повідомлення реєструються у вигляді інцидентів на відповідальних осіб або відділи.
Це свого роду ЦУП і перший рубіж оборони у разі аварії в дата-центрі.


Центр моніторингу на майданчику OST.

У кожному профільному відділі можна додатково повісити екрани зі схемами і оповіщеннями, які входять в зону відповідальності даного відділу: для інженерів експлуатації – одні екрани, для мережевиків – інші.

Візуалізація
Стежити за роботою дата-центру лише за допомогою повідомлень можна, але для наочності основні інженерні системи та їх параметри варто візуалізувати у вигляді схем і карт.


Зведена схема дата-центру OST-2.

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

Різний час опитування для різних систем
Враховуйте специфіку інженерних систем при налаштуванні часу опитування. Для системи енергопостачання чим частіше будуть зніматися показання, тим краще. Наприклад, у нашому моніторингу значення напруги знімаються кожну секунду. А для кондиціонерів, це занадто часто, досить і хвилинного інтервалу.

Встановлюйте різний час опитування для різних систем. Так ви не пропустите важливих подій і не перезавантажте систему занадто частими запитами.

Правильно вибрані порогові значення для повідомлень
Прописуйте критичні значення, по досягненні яких будуть спрацьовувати оповіщення. Краще передбачити як мінімум два рівня оповіщення – попередження і критичні помилки. У Nаgios, наприклад, такого поділу відповідають warning і critical:

  • warning попереджає про те, що якісь параметри обладнання або системи підходять до критичного значення;
  • critical означає аварійну ситуацію, коли щось зламалося, помилка в обладнанні.
Правильне поділ повідомлень дозволить скоротити кількість помилкових тривог. Провести чітку межу між warning і critical складно, але розуміння приходить з досвідом. Якщо монітор перманентно червоний від аварій, значить щось настроєно неправильно. Для інженера такий моніторинг швидко стане неінформативним, будуть виникати помилкові тривоги, а справжні аварії можуть залишитися непоміченими серед рутинних сповіщень.

При необхідності коректуйте порогові значення для різних типів повідомлень.

Приклади warning і alarm


Всі повідомлення про аварії повинні бути актуальними. Якщо на екрані висить повідомлення про аварії, то значить, що вона відбулася тільки що. Як тільки це повідомлення зареєстровано у вигляді інциденту на відповідальну особу, воно повинно зникнути з екрану.

Чіткий регламент дій при аварійних ситуаціях
Не пропустити аварію важливо, але ще важливіше правильно на неї зреагувати і запустити процес реакції на інцидент.

У чергового інженера повинна бути чітка інструкція, за якою він діє, і контакти людей, яких потрібно оповістити у разі аварійної ситуації.

Вся інформація має бути перед очима і ясно сформульована, щоб інженеру не доводилося витрачати час на пошуки або розшифрування пунктів інструкції.

Для зручності чергових інженерів кожне повідомлення можна супроводити спливаючій підказкою з контактами відповідальної особи та інструкцією. Регламенти ж прописуються заздалегідь і перевіряються на життєздатність під час планових тестувань.

Не змушуйте чергового інженера придумувати план дій з нуля, коли в дата-центрі аварія.

Сповіщення по email та смс
Річ корисна при правильному використанні. Для невеликих серверних такі оповіщення можу замінити цілодобового чергового інженера. У великому дата-центрі це свого роду резервування чергового інженера. Але і тут важливо не перестаратися і не розсилати повідомлення відповідальним особам по кожному чиху.

Якщо буде багато повідомлень з некритичним помилок (вище ми називали їх warning), то з часом їх просто почнуть ігнорувати, і серйозна аварія залишиться непоміченою.

Збір статистики
Крім онлайн-моніторингу, корисно збирати і довгострокову статистику. Це дозволить оцінити параметри в динаміці, виявити значення, що призводять до аварійних ситуацій. З цією статистикою можна робити висновки по роботі устаткування при різному навантаженні, різних погодних умовах. Ця ж інформація потім використовується для розбору польотів після аварій.

Це всі моменти, які ми хотіли б відзначити окремо, перш ніж вирушати в розповіді про моніторинг конкретних інженерних систем. У наступній статті розберемо, що і як потрібно моніторити в системі енергопостачання дата-центру і серверної.
Джерело: Хабрахабр

0 коментарів

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