Pull to refresh
0
King Servers
Хостинг-провайдер «King Servers»

Как управлять инфраструктурой в сотни серверов и избежать проблем: 5 советов от инженеров King Servers

Reading time 6 min
Views 13K


В блоге на Хабре мы много пишем о построении ИТ-инфраструктуры — например, раскрываем вопросы выбора дата-центров в России и США. Сейчас в рамках King Servers работают сотни физических и тысячи виртуальных серверов. Сегодня наши инженеры делятся советами по управлению инфраструктурой таких размеров.

Автоматизация очень важна


Для управления инфраструктурой такого масштаба один из самых важных элементов успеха — налаженный мониторинг. Поскольку вручную мониторить такое количество серверов физически нереально даже при большом штате инженеров, необходимо использовать автоматизацию. Система должна сама находить возможные проблемы и оповещать о них. Чтобы такой мониторинг был максимально эффективным, нужно заранее предусмотреть все возможные точки отказов. Проблемы должны выявляться на начальных этапах в автоматическом режиме, чтобы инженеры успели принять необходимые действия в штатном режиме а не восстанавливать уже упавшие сервисы.

Также важно максимально автоматизировать рутинные действия. Установить ключи поддержки на 10 серверов — это одна задача, а когда необходимо охватить три сотни — совсем другая.

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

И, конечно же, все автоматически сгенерированные уведомления должен получать не один инженер. Даже при наличии продуманной автоматизации эффективно администрировать сотни сервисов совсем маленькая команда из одного-двух инженеров не сможет. Правильным вариантом будет постоянное присутствие одного из инженеров онлайн. По нашему опыту для этого необходимо минимум 4 инженера.

Резервирование и бэкапы спасают в критических ситуациях


В случае крупной инфраструктуры резервирование становится еще более важным, поскольку в случае сбоя пострадает большое количество пользователей. Стоит резервировать:

  • Мониторинг серверов — необходимо не только создать систему мониторинга сбоев, но и использовать инструменты «мониторинга мониторинга».
  • Инструменты управления.
  • Каналы связи — если в вашем дата-центре лишь один провайдер, то в случае сбоя все ваше железо будет полностью отрезано от мира. Недавно мы столкнулись со сбоев канала в нашем ЦОД в Нидерландах — если бы там не было резервирования канала, то сервис для сотен наших клиентов был бы остановлен, с соответствующими последствиями для бизнеса.
  • Линии электропитания – в современных ЦОД есть возможность подведения 2 независимых линий электропитания к стойкам. Не стоит этим пренебрегать и экономить на дополнительных блоках питания для серверов. В случае если у вас уже куплено много серверов, в которые невозможно установить запасной блок питания – можно установить оборудование для автоматического ввода резерва, которое предназначено для подключения оборудования с одним блоком питания к 2 вводам.
  • Любое оборудование требует периодического технического обслуживания, и вероятность того, что в ЦОД будут проводится работы с отключением одной из линий питания – 100%
  • Если повезет – работы будут не на вашей линии питания, но рисковать не стоит.
  • Мало того, что сервисы могут быть недоступны несколько часов, так еще и существует вероятность, что часть серверов после резкого отключения питания сами не поднимутся, и потребуется вмешательство инженеров.
  • Железо — даже в случае качественного оборудования всегда есть вероятность отказа, поэтому наиболее важные элементы должны дублироваться и на уровне аппаратного обеспечения. К примеру, в серверах чаще всего отказывают диски, так что использование RAID-массивов с резервированием — хорошая идея, как и резервирование на уровне сети, когда один сервер подключен к разных свитчам, что позволяет не терять трафик при выходе одного устройства из строя. Также необходимо иметь хотя бы минимальный запас запасных частей. Выход из строя комплектующих у качественного оборудования маловероятен, но не невозможен.

Регулярное резервное копирование и тестирование развертывание бэкапов — также абсолютно обязательный элемент работы по управлению любой инфраструктурой. Когда нужно резервировать много данных и делать резервные копии часто, важно не забывать следить за производительностью сервера, на который сохраняется бэкап. Вполне может оказаться так, что данных уже стало слишком много, поэтому и бэкап еще не успел завершиться, а уже начинается новый.

Составление документации и логи


Когда проект поддерживают несколько инженеров, очень важно по мере модернизации инфраструктуры документировать рабочие процессы. С самого начала следует завести собственную базу знаний и вместе с введением новых опций составлять документацию по работе с ними. Даже если все те, кто поддерживает проект, уже знают что и как работает. При расширении команды инженеров хорошо составленная документация поможет сильно ускорить процесс ознакомления нового члена команды с проектом.

Не стоит забывать, что написание скриптов – тоже разработка и при работе над скриптом нескольких человек нужно обзавестись системой контроля версий и отслеживать изменения, чтобы при возникновении проблем можно было быстро откатиться на предыдущую версию.

Когда над одной задачей работает несколько человек важно передавать информацию о том, что было сделано. Заметно сократит время ведение подробных логов работ в автоматическом режиме и хранение их на центральном сервере. Это упростит передачу задачи другому человеку(не придется уточнять какие действия производились, все будет в лог файле).

Важно анализировать время реакции инженеров дата-центра


Все адекватные современные дата-центры предоставляют услугу remote hands, в рамках которой при возникновении проблем владелец серверов может попросить инженеров на площадке произвести с оборудованием необходимые действия. Но не всегда в итоге площадки оказывают ее качественно. Причин может быть много, одна из самых частых — высокая загрузка специалистов, или отсутствие некоторых инженеров на площадке (один из дата-центров в США предлагал нам такую опцию — выезд инженера в течение рабочего дня), но в критических ситуация время реакции очень важно, а возникнуть проблема может не только в рабочее время.

Поэтому не стоит сразу переносить всю инфраструктуру в один ЦОД, переезд лучше осуществлять поэтапно, это позволит выявить возможные проблемы до того момента, когда предпринимать какие-то меры будет уже слишком сложно и дорого.

Также вполне может оказаться, что после того как вы перевезли оборудование и аккуратно уложили все кабели, по прошествии пары лет и нескольких десятков запросов на помощь в рамках услуги remote hands картина будет выглядеть так:



И при работах начнут возникать проблемы, когда из-за обилия кабелей один сервер невозможно извлечь из стойки, не нарушив работы других серверов. Важно периодически проверять состояние стоек и просить сотрудников ЦОД делать фотографии.

Не нужно стремиться к экономии, экспериментировать лучше аккуратно


Необходимо внимательно изучать характеристики оборудования — это позволит точнее спрогнозировать возможные проблемы. К примеру, в случае SSD немного лишнего потраченного на анализ времени может получить железо, которое проживет значительно дольше, чем купленное в спешке.

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

В своем проекте мы уже многие годы используем продукцию компании SuperMicro — с этими серверами не случалось каких-то серьезных беспричинных сбоев. Также не так давно очень осторожно начали работать с оборудованием Dell. У продукции этой компании отличная репутация, но резко наращивать объемы работы с новым железом всегда рискованно, поэтому мы двигаемся постепенно.

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



Ничем хорошим это не закончится, особенно, если инфраструктуру используют внешние заказчики – в сфере хостинга нередка ситуация, когда пользователь покупает виртуальный сервер для бизнеса, но забывает делать бэкапы или не тестирует их развертывание (так и выглядит экономия малого бизнеса на администраторах). Если при этом еще и физический сервер будет собран наполовину из десктопных компонентов, то очень скоро произойдет сбой с полной потерей данных — это может просто убить чей-то бизнес. Такого допускать нельзя.

Больше полезных ссылок и материалов от King Servers:


Tags:
Hubs:
+19
Comments 21
Comments Comments 21

Articles

Information

Website
king-servers.com
Registered
Founded
Employees
11–30 employees
Location
Россия