В блоге на Хабре мы много пишем о построении ИТ-инфраструктуры — например, раскрываем вопросы выбора дата-центров в России и США. Сейчас в рамках King Servers работают сотни физических и тысячи виртуальных серверов. Сегодня наши инженеры делятся советами по управлению инфраструктурой таких размеров.
Автоматизация очень важна
Для управления инфраструктурой такого масштаба один из самых важных элементов успеха — налаженный мониторинг. Поскольку вручную мониторить такое количество серверов физически нереально даже при большом штате инженеров, необходимо использовать автоматизацию. Система должна сама находить возможные проблемы и оповещать о них. Чтобы такой мониторинг был максимально эффективным, нужно заранее предусмотреть все возможные точки отказов. Проблемы должны выявляться на начальных этапах в автоматическом режиме, чтобы инженеры успели принять необходимые действия в штатном режиме а не восстанавливать уже упавшие сервисы.
Также важно максимально автоматизировать рутинные действия. Установить ключи поддержки на 10 серверов — это одна задача, а когда необходимо охватить три сотни — совсем другая.
Важно понимать, что инфраструктура имеет свойство со временем увеличиваться в размерах. При этом обычно количество инженеров в компании не увеличивается соответствующими темпами. Во избежание проблем внедрять автоматизацию нужно сразу, даже если на текущий момент кажется, что можно справиться руками. Очень часто встречается ошибка, когда кажется, что если действие повторяется раз в неделю, то не нужно его автоматизировать. На самом деле время, затраченное на написание скрипта, окупится в течение ближайшего времени за счет сокращения времени на выполнение повторяющихся действий. Также при подобном подходе со временем наберется база скриптов, ориентированная именно под вашу инфраструктуру и будет возможно использование уже готовых фрагментов кода в новых скриптах, что также сэкономит время.
И, конечно же, все автоматически сгенерированные уведомления должен получать не один инженер. Даже при наличии продуманной автоматизации эффективно администрировать сотни сервисов совсем маленькая команда из одного-двух инженеров не сможет. Правильным вариантом будет постоянное присутствие одного из инженеров онлайн. По нашему опыту для этого необходимо минимум 4 инженера.
Резервирование и бэкапы спасают в критических ситуациях
В случае крупной инфраструктуры резервирование становится еще более важным, поскольку в случае сбоя пострадает большое количество пользователей. Стоит резервировать:
- Мониторинг серверов — необходимо не только создать систему мониторинга сбоев, но и использовать инструменты «мониторинга мониторинга».
- Инструменты управления.
- Каналы связи — если в вашем дата-центре лишь один провайдер, то в случае сбоя все ваше железо будет полностью отрезано от мира. Недавно мы столкнулись со сбоев канала в нашем ЦОД в Нидерландах — если бы там не было резервирования канала, то сервис для сотен наших клиентов был бы остановлен, с соответствующими последствиями для бизнеса.
- Линии электропитания – в современных ЦОД есть возможность подведения 2 независимых линий электропитания к стойкам. Не стоит этим пренебрегать и экономить на дополнительных блоках питания для серверов. В случае если у вас уже куплено много серверов, в которые невозможно установить запасной блок питания – можно установить оборудование для автоматического ввода резерва, которое предназначено для подключения оборудования с одним блоком питания к 2 вводам.
- Любое оборудование требует периодического технического обслуживания, и вероятность того, что в ЦОД будут проводится работы с отключением одной из линий питания – 100%
- Если повезет – работы будут не на вашей линии питания, но рисковать не стоит.
- Мало того, что сервисы могут быть недоступны несколько часов, так еще и существует вероятность, что часть серверов после резкого отключения питания сами не поднимутся, и потребуется вмешательство инженеров.
- Железо — даже в случае качественного оборудования всегда есть вероятность отказа, поэтому наиболее важные элементы должны дублироваться и на уровне аппаратного обеспечения. К примеру, в серверах чаще всего отказывают диски, так что использование RAID-массивов с резервированием — хорошая идея, как и резервирование на уровне сети, когда один сервер подключен к разных свитчам, что позволяет не терять трафик при выходе одного устройства из строя. Также необходимо иметь хотя бы минимальный запас запасных частей. Выход из строя комплектующих у качественного оборудования маловероятен, но не невозможен.
Регулярное резервное копирование и тестирование развертывание бэкапов — также абсолютно обязательный элемент работы по управлению любой инфраструктурой. Когда нужно резервировать много данных и делать резервные копии часто, важно не забывать следить за производительностью сервера, на который сохраняется бэкап. Вполне может оказаться так, что данных уже стало слишком много, поэтому и бэкап еще не успел завершиться, а уже начинается новый.
Составление документации и логи
Когда проект поддерживают несколько инженеров, очень важно по мере модернизации инфраструктуры документировать рабочие процессы. С самого начала следует завести собственную базу знаний и вместе с введением новых опций составлять документацию по работе с ними. Даже если все те, кто поддерживает проект, уже знают что и как работает. При расширении команды инженеров хорошо составленная документация поможет сильно ускорить процесс ознакомления нового члена команды с проектом.
Не стоит забывать, что написание скриптов – тоже разработка и при работе над скриптом нескольких человек нужно обзавестись системой контроля версий и отслеживать изменения, чтобы при возникновении проблем можно было быстро откатиться на предыдущую версию.
Когда над одной задачей работает несколько человек важно передавать информацию о том, что было сделано. Заметно сократит время ведение подробных логов работ в автоматическом режиме и хранение их на центральном сервере. Это упростит передачу задачи другому человеку(не придется уточнять какие действия производились, все будет в лог файле).
Важно анализировать время реакции инженеров дата-центра
Все адекватные современные дата-центры предоставляют услугу remote hands, в рамках которой при возникновении проблем владелец серверов может попросить инженеров на площадке произвести с оборудованием необходимые действия. Но не всегда в итоге площадки оказывают ее качественно. Причин может быть много, одна из самых частых — высокая загрузка специалистов, или отсутствие некоторых инженеров на площадке (один из дата-центров в США предлагал нам такую опцию — выезд инженера в течение рабочего дня), но в критических ситуация время реакции очень важно, а возникнуть проблема может не только в рабочее время.
Поэтому не стоит сразу переносить всю инфраструктуру в один ЦОД, переезд лучше осуществлять поэтапно, это позволит выявить возможные проблемы до того момента, когда предпринимать какие-то меры будет уже слишком сложно и дорого.
Также вполне может оказаться, что после того как вы перевезли оборудование и аккуратно уложили все кабели, по прошествии пары лет и нескольких десятков запросов на помощь в рамках услуги remote hands картина будет выглядеть так:
И при работах начнут возникать проблемы, когда из-за обилия кабелей один сервер невозможно извлечь из стойки, не нарушив работы других серверов. Важно периодически проверять состояние стоек и просить сотрудников ЦОД делать фотографии.
Не нужно стремиться к экономии, экспериментировать лучше аккуратно
Необходимо внимательно изучать характеристики оборудования — это позволит точнее спрогнозировать возможные проблемы. К примеру, в случае SSD немного лишнего потраченного на анализ времени может получить железо, которое проживет значительно дольше, чем купленное в спешке.
Следует готовиться и к тому, что такой подход не позволит сэкономить здесь и сейчас. В долгосрочной перспективе экономия на железе оборачивается убытками — более низкая цена всегда компенсируется низкой надежностью, а ремонт и замена железа в итоге часто стоят дороже, чем покупка более дорогого оборудования, который проживет дольше.
В своем проекте мы уже многие годы используем продукцию компании SuperMicro — с этими серверами не случалось каких-то серьезных беспричинных сбоев. Также не так давно очень осторожно начали работать с оборудованием Dell. У продукции этой компании отличная репутация, но резко наращивать объемы работы с новым железом всегда рискованно, поэтому мы двигаемся постепенно.
Что касается комплектующих, то эксперименты здесь также неуместны — лучше быть параноиком и доверять только проверенным поставщикам, пусть это и не позволит сэкономить здесь и сейчас. Точно также категорически не стоит даже в минимальном количестве использовать в сервера комплектующие для десктоп-компьютеров — это совершенно разные классы устройств, рассчитанные на кардинально иные нагрузки.
Ничем хорошим это не закончится, особенно, если инфраструктуру используют внешние заказчики – в сфере хостинга нередка ситуация, когда пользователь покупает виртуальный сервер для бизнеса, но забывает делать бэкапы или не тестирует их развертывание (так и выглядит экономия малого бизнеса на администраторах). Если при этом еще и физический сервер будет собран наполовину из десктопных компонентов, то очень скоро произойдет сбой с полной потерей данных — это может просто убить чей-то бизнес. Такого допускать нельзя.
Больше полезных ссылок и материалов от King Servers:
- Бесплатный тест инфраструктуры от King Servers
- Как и зачем мы создавали базу знаний
- Как выбрать дата-центр для ИТ-проекта в России: аптайм, деньги и общая адекватность
- Статистика популярности операционных систем в IaaS: Ubuntu пока номер один, популярность CentOS растет
- Когда ломается «облако»: что можно сделать в этой ситуации?
Комментарии (21)
antiBILLotic
17.02.2018 16:49Маловато конкретики, вся статья — общие слова и рекомендации. И пускай повторять, в общем-то, общеизвестные практики — мысль хорошая, но хотелось бы почитать про конкретную реализацию. Какая система мониторинга, как резервируется, как/через что организованно автоматизированная настройка и подключение имеющихся и приходящих серверов к развёрнутым системам? Что именно служит сигналом о потенциальных сбоях в обозримом будушем? Какова методология превентивного обслуживания и замены оборудования? Как реализовано тестовое развёртывание бекапов, о котором говорится? Чем анализируются логи (не руками же)? И что туда отправляется — только информация с IPMI/BMC или агенты логов и мониторинга также ставятся на физические/виртуальные ОС? Если последнее — как ведётся агрегация логов? Ведь одно дело — завернуть syslog в *nix-подобных системах на один общий сервер, и совсем другое — завернуть туда же Event Log из Windows-систем, тут есть свои сложности.
nikolau
17.02.2018 17:29Хотел бы уточнить про резервный канал интернета, как это реализуется. Допустим есть клиенты, у которых есть выделенные ip адреса. При подключении резервного канала — они останутся? Вот в домашнем интернете, например, не получится два канала (с резервным) подключить, чтобы ip адрес был один.
scruff
17.02.2018 18:30Я думаю тут скорее всего идет речь об автономной системе BGP, может даже не одной. При падении одного линка/провайдера переключается все на другой без потери выделенных IP.
BigD
17.02.2018 21:12мне вот любопытно, в грядущем мире ipv6 (который все никак не дойдет до нас) — может ли простой обыватель получить AS и использовать в домашних условиях?
Refakki
17.02.2018 21:18Давно у простого обывателя 2 аплинка с BPG пирами и маршрутизатор за 30-40 тысяч руб и выше?
А так да, можно получить и пользоваться. Договориться нужно только.AccessForbidden
18.02.2018 00:29Тут вопрос только в том кто такой обыватель.
1. Получить свою ASN и адреса можно заключив договор поддержки с любым LIR.
2. Роутер вполне подойдёт… любой. Вам не надо принимать full-view, достаточно default route, а с этим справится любой роутер с чем то типа openwrt/routeros или даже голый *nix.
3. Про 2 аплинка требование конечно хорошее, но на практике в RIPE на это закрывают глаза.
Так что если очень хочется, то можно.
vikarti
18.02.2018 03:03Получить частном лицу можно было и с IPv4 (обоснование ЗАЧЕМ нужно /24 все же писать надо было более менее серьезное) и платить LIR'у
Затем например схема с сервером в хорошем DC кто примет BGP (и это был не Российский DC), два VPN-туннеля (живущих со своих маленьких виртуалок и имеющих приватные AS), прибитых к интерфейсам провайдеров, Quagga или Vyatta (и то и другое пробовалось, это ж еще и упражнение было хорошее) в еще одной виртуалке дома и все работает. Все домашнее железо имеет public IP доступные при падении любого одного из провайдеров(падает и соответствующий VPN и BGP-линк в Quagga).
p.s. с некоторого момента было решено что оно того не стоит, LIR'у дальше не проплачивалось и адреса вернулись RIPE'у
Hardened
18.02.2018 08:47Как раз есть интерес к организации подобной схемы. Почитал бы статью на хабре или ссылки на материалы по теме в личке. Спасибо.
vikarti
18.02.2018 20:35Ушло в личку. На статью на хабре имхо оно не тянет.
Кстати а интересно — King Servers согласится поднять BGP-пир с сервером клиента и анонсировать клиентскую PI /48? и сколько за это возьмут денег?scruff
19.02.2018 06:05Скиньте, пожалуйста и мне в личку. Очень интересен данный материал. Спасибо.
vikarti
19.02.2018 09:19Замечание: некоторые решения могут быть… не очень оптимальными, я по профессии не сетевик (а программист)
Конфигов к сожалению не сохранилось.
все в районе конца нулевых было было по этому не все записи сохранились.
регистрация AS и IPv4 PI была через ipaddr.ru (рассматривался вариант и с www.netassist.ru/node/31 )
возможность регистрации физического лица — они прямо предусматривают — ipaddr.ru/faq (но про план сети, оборудование и так далее — они серьезно, надо хоть что-то хоть как то обоснованное, у меня был в том числе перечень уже используемого по разным хостингам железа и адресов)
сервер брался goscomb.net (документы частного лица их устроили) (потом был digitalone)
в России вроде selectel может официально дать BGP (но вот не факт что даст частному лицу без идиотских требований)
схема (одна из записанных промежуточных версий)
на сервере 'в мире' Quagga с публичным номером AS и BGP-пиром полноценным (c FullView кстати — а так интереснее) + VPN-сервер настроенный на статичные 2 туннеля (+немного адресов на самом сервере используется)
дома
2 канала от двух провайдеров
сервер дома
на нем виртуалки
на №1 default route настроен на провайдера 1
на №2 default route настроен на провайдера 2
(зачем виртуалки для туннелей? Ну… мне было проще так сделать)
на №3 (хотя вообще это хост был)- Quagga (opensource BGP-демон, форк Zebra)(с Vyatta-спецдистрибутив для роутеров — тоже был вариант), пиринг по BGP(с приватными AS) с 'главным сервером' поверх OpenVPN-туннелей. она же — главный роутер.
BGP keealive выкручен в минимум (он 60 секунд по умолчанию — поставлено было вроде 3) + 'ping 1'
и локалпрефами заданы приоритеты (провайдер№2 еще и по каналу уже раз так в 10 — это ADSL был)
Сейчас бы делалось по другому — если сервер нам И ТАК отдаст PA /48 IPv6 (а нормальный хостер — даст) — то зачем нам PI /48? можно просто использовать те адреса что есть (недостаток — при смене хостера придется менять адресацию).
Зачем вообще все это надо было: доступные извне белые адреса (были серверы во внутренней сети), балансинг канала + НЕ разрыв долгоживущих TCP-соединений при переходе на резервный канал (с точки зрения конечных устройств же поменялся только маршрут а адреса — прежние).
Ну и опыт.
Если бы нужен был просто балансинг внешнего канала а требование про серверы и обеспечение непрерывности TCP-сессий — не нужно — то значительно проще было было настроить т.н. Dual-WAN (так даже многие продвинутые роутеры умеют, Mikrotik точно, режим либо основной-резервный либо даже балансировка по TCP-соединениям (+исключение — есть сайты — например все банки, которые не любят когда к ним в рамках одного сеанса идут с разных IP)
При Dual-WAN да — будет два внешних IP-адреса.
Настройка Dual-WAN очень легко гуглится.(например можно начать с habrahabr.ru/post/49137 habrahabr.ru/post/55132 )
Как вообще BGP работает — например habrahabr.ru/post/184350 (но этого мало)
как проверить что правильно сидим — идем на www.subnets.ru/wrapper.php?p=28 и смотрим провайдера (должна быть наша AS)
scruff
19.02.2018 06:03А смысл в отдельной AS? Домохозяйки ведь не смогут полноценно админить железку. От таких понятий как BGP-session или full-view им ни холодно ни жарко. Вот если дома у вас подобие приватного облака в кладовке, то смысл в АС есть. Но тогда избыточность проще организовать на уровне железки без BGP. Многие раутеры уже давно «умеют» ISP-redundancy.
vikarti
19.02.2018 09:30А это все — НЕ для домохозяек.
Если человек в принципе не понимает что такое BGP и зачем ему это надо — ЕМУ ЭТО — НЕ НАДО (забудет аплинк фильтры настроить и привет порушенный сервис какой нибудь на половине континента потому что товарищь ошибся в настройках или (вроде бы сейчас внедряют подпись маршрутов чтобы как раз избежать таких проблем ). кто-нибудь напишет странный конфиг + баг в софте и привет мигающий BGP у кучи людей — как в habrahabr.ru/company/qrator/blog/340356 )
Если надо просто резервирование домашнего доступа без дополнительных требований — Dual-WAN умеет куча даже домашних роутеров (ну да — разорвутся TCP-сессии + сменится внешний адрес, зато значительно дешевле и значительно проще в настройке, и не забивается кстати память у других BGP-роутеров с FullView еще одной строкой).
osipov_dv
интересно, если устраивали supermicro, зачем идти на более дорогой dell? Случайность, не думаю :)
dklm
А почему вы решили что они дороже?
В далеком 2011 при заказа 50 серверов HP получились дешевле чем supermicro.
А сервис которые предоставляет HP не сравним по «качеству» с supermicro.
*Все выше написанное это мой личный опыт ;-) и может не совпадать с вашим…
osipov_dv
Они так позиционируются, если не получать скидку от вендора, то действительно дешевле раза в 2. На уровне самосбора — чем собственно и является. За 50 серверов, конечно, hp должен был хорошую скидку дать. У DELL немного другой формат, насколько я помню, у них нет серверов в наличии. Все идет под конкретный заказ, и некоторое время назад было дешевле HP… и не было как такового GPL, ценник давали при конкретном запросе.
KingServers
На самом деле у делл не дороже, если только не много. Для партнеров они дают хорошие скидки, которые не видно на сайте