Предположим, вам поручено запустить набор критически важных веб-сервисов с целевым временем работы 99,5%.
Для этого у вас есть два идентичных кластера оборудования в двух совершенно разных центрах обработки данных с разными поставщиками полосы пропускания и т. Д.
В верхней части каждой стойки должно быть какое-то оборудование стойки (оборудование коммутации и брандмауэра).
Ваше программное обеспечение настроено так, что при вмешательстве человека очень легко перенаправить все службы из одного центра обработки данных в другой в случае выхода из строя одного из кластеров. Скажем, это займет около 15 минут.
Вопрос в следующем: потратите ли вы на центр обработки данных 8 тысяч дополнительных, чтобы не было единой точки отказа наверху оборудования стойки (переключение с горячим отказом и межсетевые экраны). Для справки, в каждой стойке оборудования около 50к серверов.
Резервная установка намного сложнее, имеет больше режимов отказа и гарантированно будет стоить как с точки зрения начальной закупочной цены, так и с точки зрения времени, затрачиваемого на обслуживание и устранение неисправностей более сложной установки.
Кроме того, мы эксплуатируем (дублирующую) установку более 8 лет и ни разу (постучать по дереву) не вышли из строя верхнее оборудование стойки. Мы заменяем все свое оборудование через 3 года в сервисном цикле.
Обратной стороной модели единой точки отказа является то, что если мы потеряем коммутатор или брандмауэр, весь центр обработки данных выйдет из строя. Кроме того, человек должен переключиться, чтобы направить отказавшие службы в другой центр обработки данных (по разным причинам не существует надежного способа сделать это автоматически).
Я подозреваю, что, потому что он использует меньше оборудования и проще вариант единой точки отказа приведет к увеличению времени безотказной работы в реальном мире. По моему опыту, сбои оборудования происходят гораздо реже, чем сбои людей, и переключатели / брандмауэры (без вращающихся дисков и защищенных ОС и т. Д.) Редко выходят из строя ...
Что думает сообщество по сбоям сервера?
Что бы вы ни делали, оборудование выйдет из строя. Люди будут ошибаться.
Без тени сомнения я бы модернизировал каждую стойку, чтобы в ней было всего несколько штук.
Вы говорите, что у вас 50 тысяч серверов в каждой стойке, но только один коммутатор, соединяющий их с внешним миром? Я полагаю, также один маршрутизатор и один межсетевой экран.
Я не уверен, что смог бы лично справиться с этим, будь я сисадмином. Я бы потребовал, чтобы несколько разных транзитных провайдеров, пара граничных маршрутизаторов в режиме HA / HSRP, пара межсетевых экранов высокой доступности, как минимум 2 коммутатора, и все серверы с двумя сетевыми адаптерами имели разные переключатели на каждой из сетевых карт.
STP обрабатывает отказ коммутатора или порта, это происходит автоматически. Отказ маршрутизатора обрабатывается программным обеспечением высокой доступности пары. То же самое с межсетевыми экранами. Потеря центра обработки данных и переключение трафика между ними, я полагаю, вы используете какую-то форму устройства GSLB?
Я полностью согласен с вашей идеей, но проблема в том, что, допустим, DC1 отключается из-за серьезного инцидента, это займет несколько дней или недель, чтобы снова вызвать это (пожар, наводнение, действие $ imaginary_deity) ... тогда у вас сбой маршрутизатора в DC2. Это не такой уж и невозможный сценарий. Судя по тому, что вы нам сообщили, вся ваша инфраструктура теперь недоступна из Интернета.
Это один из допустимых режимов отказа? Я бы точно не потерпел такого простоя, если его так легко (не дешево) избежать.
Я полагаю, если вы проведете оценку риска для такого рода сбоев и учесть потерянный бизнес, который может пострадать ваш работодатель, если стоимость обновления меньше, чем потеря бизнеса в течение недели, то это хорошая сделка.