Как стать автором
Обновить

«Тушить» ли сервера, если «загорелся» смоук тест датацентра?

Время на прочтение 9 мин
Количество просмотров 32K
Всего голосов 90: ↑86 и ↓4 +82
Комментарии 47

Комментарии 47

НЛО прилетело и опубликовало эту надпись здесь
А чем обусловлена балансировка на уровне DNS? Ведь если нужно будет очень срочно убрать трафик с какой-то из локаций, то все равно он уйдет только через TTL-секунд.

Анонсируя ebgp какой-то один VIP, прописываемый в DNS — это не так эффективно? Там и анонс убрать намного быстрее получится.

Возможно, я заблуждаюсь и говорю немного не о том, но все-таки хотелось бы услышать о таком решении.
Про балансировку трафика можно почитать в статье «Балансировка нагрузки и отказоустойчивость в «Одноклассниках»».
В целом — у обоих решений есть свои плюсы и минусы.
Например, во время недоступности дата-центра-погорельца в другом дата-центре вылетел диск на одном из серверов, то есть осталась доступна только одна из трёх реплик в Cassandra-кластере

А можно подробностей, как так вышло что один сбойный диск положил реплику?
Вполне возможно что при вылете одного из диска в массиве, скорость всего массива сильно падает и не справляется с нагрузкой, забивается очередь реплики и она отваливается. Так, чисто предположение.
Данные в кассандре и так хранятся в 3 экземплярах (не считая бекапов), поэтому тут мы не используем массивы.
Это всё объясняет.
Но тогда имеет смысл, например, удвоить или утроить число реплик, сделав по две (или три) на каждый ДЦ (не знаком с архитектурой Cassandra)?
Кажется, данный случай на это намекает
Такое решение было бы экономически неэффективным. В кассандрах сейчас хранится более 100PB данных в более чем 1000 нод. По такой схеме нам бы пришлось доставить еще грубо 1 или 2 тысячи нод.
Мы сейчас смотрим больше в сторону полной автоматизации замены сбойных нод — что позволит снизить время недоступности оных изза отказа железа. Временная репликация тоже выглядит многообещающе, будем пробовать внедрять.
Конкретно же с этим случаем, отказавший сервис не должен был влиять на доступность логина, это было ошибочное поведение.
Сервисы, связанные с доступностью логина и другими критическими функциями резервируются у нас обычно с RF=5 вместо 3.
Потому что на этой реплике один диск с данными.
Да
Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.

Везет вам, вас предупредили
А я об инциденте узнал в 15.15 постфактум от заббикса. Дозвониться до саппорта было невозможно, поэтому о причинах я вообще узнал из новостей стороннего телекомовского чатика куда более удачливый коллега скинул информацию.
Вот так вот читаешь на сайтах про всякие Tier III спецификации, надежность и резервирование, а в реале при аварии саппорт даже примерные сроки восстановления сказать не может
В каждом нашем дата-центре каждый день работают наши инженеры. В здании сработала пожарная тревога, они её услышали и рассказали это нам.
Были ли какие-то проблемы со службой поддержки мне не известно, но судя по вот этой статье служба поддержки тоже пострадала от пожара:
Потеря каналов связи из-за пожара внутри компании и с клиентами усугубила ситуацию. После пожара Dataline задублировала все каналы связи и внутренние сервисы в своих дата-центрах Nord и Ost.
Всё зависит от того, есть ли под рукой необходимые запчасти и специалисты. 100% надёжности ни один Tier не подразумевает, и вряд ли даже гарантирует соблюдение своих нормативов по срокам восстановления особенно если ответственность по SLA грамотный юрист оценил в копейки.
почему бы не автоматизировать аварийное последовательно отключение \включение оборудования?
Это уже сделано в нашем облаке, куда мы активно мигрируем весь наш продакшен. В конце статьи об этом написано.
НЛО прилетело и опубликовало эту надпись здесь
Мы используем MS SQL уже 13 лет, начиная с первых версий сайта. За это время мы вкусили всего его прелести (которых безусловно не мало) и недостатки. Примерно столько же лет мы планомерно переходим на Open Source решения (даже вебсервера в первые годы жизни проекта работали на решениях Microsoft). Что касается баз данных, то для критичных систем мы стараемся использовать NoSQL решения и собственные разработки.
импортозамещение, подозреваю. а дальше уже все остальное.
Странный вопрос, выключать ли серваки при пожарной тревоге, помоему при любом раскладе нужно выключать серваки, даже если пожара именно в ваших залах нету то сеть-электричество может отвалиться палюбому. Так что лучше пусть пользоваатели 1-2 часа поноют, чем потом вычищать глюки в базах
Удовлетворённость пользователей для нас очень важна, так же как и сохранность данных. Однако, в данном случае угрозы потери данных не было, поэтому мы делали всё, что бы и пользователи не пострадали.
15:16. Принято решение о выключении всего оборудования.
15:21. Начинаем отключать питание на stateless-серверах без корректного выключения приложения и операционки.
Пяти минут не хватило, чтобы зайти по SSH на каждый из серверов и ввести в терминал
 /etc/init.d/nginx stop && poweroff
или что-то подобное?
А как же порядок выключения? Отключишь так первым сервер, через который идёт ssh-трафик — и как остальные тогда выключать?
Зачем направлять весь SSH-трафик с доверенных IP-адресов через один сервер?
Ещё лучше. Нарушил порядок выключения — не смог выключить часть серверов… А задача же в выключении на скорость состоит, так?
Файрволлы, роутеры и свитчи надо выключать последними. И на них нет столь ценной и уязвимой информации, как на серверах.
Во-первых, нужно было собрать список серверов подходящих под нужные критерии.
Во-вторых, в этот момент мы продолжали выключать и другие сервера, поэтому свободных рук моментально не было доступно.
Остановка приложения и корректное выключение операционки для этих серверов на этом этапе уже не делалось. Просто выключали питание на всех серверах черех IPMI. Для таких задач мы используем заранее подготовленный многопоточный скрипт.
Для таких задач мы используем заранее подготовленный многопоточный скрипт.
Скрипт — это правильно: понятно, что вручную не успеть. (Скрипт полезен для корректного завершения. Для отключения электричества достаточно рубильника.)

нужно было собрать список серверов подходящих под нужные критерии.
свободных рук моментально не было доступно
То есть заранее подготовленный многопоточный скрипт в те времена ещё не использовали?
Скрипт о котором идёт речь в предыдущем комментарии получает на вход список серверов и далее может произвести с ними какие-то действия по IPMI.
Список серверов готовится на основании CMDB другими утилитами.
В тот момент авария была в самом разгаре, все занимались выключением серверов. Как только появился первый свободный администратор он занялся задачей выключения части серверов по IPMI. Отрывать кого-то от выключения серверов, что бы выключить другие сервера не имело никакого смысла. К тому же было известно, что ближайший человек освободится в течении считанных минут, а ситуация позволяла нам их ждать.
Интересно так же узнать о физических причинах пожара. Сам с пожарами не сталкивался, в серверных где присутствовал установлена автоматическая система пожаротушения. Гореть со стороны кажется нечему, современные материалы достаточно огнеустойчивы.
Если отдельно выделено здание под датацентр, источников возгорания должно быть минимум. С легким задымлением понятно, даже светодиодные светильники могут при замыкании напустить дыма, не говоря о силовом, более мощном оборудовании. Но, в тех случаях, которые я наблюдал, на этом всё и заканчивалось, 15 минут на проветривание и всё. Поэтому и интересно, как пошло распространение и поддержание горения на таком уровне, что смогло повредить систему охлаждения. Ошибка проектировщиков, упустили что-то и применили устаревшие пожароопасные материалы?
Очень качественный обзор происшествия по существу. Вот, наверное, ключевой момент пожара. Если бы не деревянные элементы (без противопожарной пропитки вероятно), гореть было бы нечему. Дерево высыхает и становится пожароопасным.
Часть проблем была связана с тем, что крыша дата-центра содержала деревянные элементы, хотя сама и была металлической, и имела сложную конструкцию. Теперь запущен технически сложный проект по созданию новой крыши с негорючими материалами
Как-раз показывает, что от небольших пожаров защищает, огнестойкость хоть в небольших пределах, но возрастает. На крыше все же не бензином поджигали, а небольшим источником тепла, немного огнестойкости и всё бы ограничилось задымлением.
Аналогичные исследования есть для проводов и гофрорукавов. Есть самозатухающие, есть такие что хорошо поддерживают горение. Вероятно, загоревшийся провод передал горение дереву. К проводу и гофре тоже могут быть вопросы.
а можно ссылку на conf?
Это внутренняя разработка. Про нее подробной информации не было в публичном пространстве, я рассказывал пару слайдов на техтрейне в прошлом году.
Можно послушать например тут: youtu.be/zfmwd52VuQ0?t=2313
жаль что пропрайтори :-)
НЛО прилетело и опубликовало эту надпись здесь
Посылка, что мы используем кассандру как одну огромную БД ложна.
Как раз недавно я рассказывал о нашем способе построения систем на основе C*.
Видео про это с Joker 2019 можно посмотреть тут: www.youtube.com/watch?v=x9tvJjWCrr4
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью! Не могу сказать, что узнал много нового, но получил огромное эстетическое удовольствие. Чуствуется слог профессионального администратора, который знает, о чем говорит, как говорит и что делает. Кратко, лаконично, по существу ) Очень правильный человек на нужном месте в одноклассниках )
Спасибо за приятные слова :)
Причем администратора, а не модного девопса )
Зарегистрируйтесь на Хабре , чтобы оставить комментарий