Законы Мерфи в IT

Автор оригинала: Ivan Pepelnjak
  • Перевод
Не так давно мне довелось беседовать с разработчиком, не понимавшим, почему полностью резервированная связь между ЦОДами не может гарантировать 100% доступность сервиса.

У клиента была идиллия: L3 связь между площадками с двумя маршрутизаторами ядра на каждой, с двумя каналами от разных операторов, предположительно выходящими из здания в разных точках и далее нигде не пересекающимися. И, несмотря на это, мы говорим разработчикам, что нельзя разносить компоненты критических приложений по разным локациям. Поразительно, правда?
Ну что может пойти не так при полностью резервированном дизайне?

Каждый задействованный вами компонент имеет отличную от нуля вероятность отказа. Следовательно, вероятность отказа нескольких компонентов разом тоже существует. Но если каждый компонент в достаточной мере надежен (скажем, доступность – 99,9%), значит, вероятность одновременного отказа крайне низка, верно? Неверно. Связанные друг с другом узлы имеют свойство падать одновременно.

Очевидный пример: если ПО маршрутизатора ядра уязвимо для пакета-убийцы (например, он вызывает падение и перезагрузку устройства), соседний роутер наверняка следом получит тот же самый пакет.

Был случай: в роутерах Cisco обнаружился баг, проявляющийся при обработке исключительно длинных AS Path. Тогда многие впервые поняли важность команды “bgp maxas-limit”. «Виновниками» были маршрутизаторы Mikrotik. Синтаксис их конфигурации очень похож на таковой у IOS маршрутизаторов, вот только там надо вводить не сам AS Path, а количество раз, которое локальная AS должна повторяться, чего некоторые администраторы не знали, ведь зачем читать документацию? Маршрутизаторы не выполняли проверку корректности введенных данных, и в результате принималось число в младших 8-и битах локальной AS. У кого-то это число было довольно высоким.

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

Разработчик все еще не верил мне, так что я рассказал ему еще одну историю.

Некоторое время назад нас уведомили, что ЦОД будет отключен от внешнего энергоснабжения на пару часов в связи с профилактикой. Не проблема – есть ДГУ, есть емкие ИБП. Но когда питание отключили – дизель не завелся, и некому было его чинить посреди ночи. К счастью, оставалось достаточно времени, чтобы корректно остановить все системы, но через час наш ЦОД был мертв, несмотря на тройное резервирование.

На это разработчик ответил «теперь я понял». Затем было уже проще сойтись во мнении по поводу того, что нужно для обеспечения истинной катастрофоустойчивости их датацентров и сервисов.

Другие примеры из комментариев.
Вот вам еще одна история про отказоустойчивость. Все внешние каналы одной крупной площадки были сосредоточены в одном здании. Было предусмотрено полное резервирование. Два внутренних маршрутизатора, два внешних, два VPNа, дублированное энергоснабжение с ДГУ. Каналы DS3 терминировались каждый на своем внешнем роутере, использовали раздельные медиаконвертеры, и выходили из здания с разных сторон.

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

Еще одна история с генератором. У одного ЦОДа обесточились вводы, и дизели завелись. Но кто-то оставил на одном из них кучу деревянных досок, и через час дизель воспламенился.

Еще про дизели, было это лет 12-13 назад. Я работал в крупном британском провайдере (не BT), и одним жарким днем (да, такое у нас бывает) я проводил кое-какие работы в одном из наших крупных ЦОДов. Я приехал рано, и застал доставку огромного контейнера. Когда я спросил, что это, мне сказали, что это – генератор, который даст немного лишней энергии – системы охлаждения работали на пределе, и питания не хватало. Я подумал «круто» и приступил к своей работе.

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

Когда я приехал туда на следующий день, на выхлоп дизеля установили огромную трубу, которая отводила дым далеко в сторону от здания ЦОДа.

У той площадки было много отказоустойчивости, но в итоге ничто не помогло…

У нас в EDU все было резервировано. Но вот одно мы исправить не могли. Машинный зал находился прямо под туалетом художественного отдела. В общем, однажды нас натурально затопило говном. А вы знали, что можно заказать у Sun Microsystems выезд их бойцов для протирки оборудования СХД ватными тампонами со спиртом?

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

Однажды клиент собирался переместить часть серверного оборудования в другое здание – чтобы освободить пространство и добавить немного отказоустойчивости. Связь заводилась по двум OC-3 от одного ОПМ, но зато по двум независимым трассам. У нас был детально проработан план переезда, предусмотрена каждая мелочь, и когда наступило время Ч – я заглушил порты, оборудование отключили и начали переносить в другое здание. Инженер был готов выдернуть оптику, провайдеру дали зеленый свет на перерезание теперь уже неиспользуемого канала. Разве что… Кто-то где-то когда-то давным-давно, когда схема еще только вводилась в эксплуатацию, перепутал местами идентификаторы каналов. Так что половина нашего ЦОДа была в процессе перевоза с места на место, а у второй половины перерезали единственный внешний канал связи. Не очень приятно.

Несколько лет назад (в районе 2005-2007гг) одна из крупных магистралей, соединяющая штат Queensland с остальной частью Австралии (да на тот момент и со всем миром), сломалась. Если я правильно помню последовательность событий, дело было так.

Магистраль шла двумя различными путями, один по побережью, другой через материк. Около 3-х часов ночи линейная карта, терминировавшая побережную оптику, начала сыпать ошибками, а потом совсем упала. Не проблема – весь трафик перемаршрутизировало через материк. Инженерам велели прибыть на место в 9 утра для замены платы… Но около 6 утра экскаватор перерубил шедшую через континент оптику.

Лет 10 назад (надеюсь, с тех пор разработчики железа поумнели) я потерял массив RAID5. На десять дисков. Началось все с того, что диск под номером «3» вылетел. Инженер идет к массиву, вынимает диск три – и массив падает. Оказалось, что управляющий интерфейс нумеровал диски с 0 по 9, а маркировка на передней панели – от 1 до 10, так что инженер вынул исправный диск.

Крупный логистический центр со всеми видами резервирования, ИБП (батареи и дизель) и все прочее. Однажды у всего квартала отключается энергоснабжение. Не беда – батареи перехватывают нагрузку, дизели заводятся, контора продолжает работать.

Питание восстанавливается. Квартал зажигается всеми огнями, контора обесточивается.
Как полагается по законам Мерфи, дизель корректно заглушили, но вот только реле, переключающее питание с дизеля на городские вводы, не сработало…

ЦОД, в котором я раньше работал, имел городские вводы электроснабжения и ИБП. ИБП брали с расчетом на 6 часов работы. В случае аварии предполагалось мигрировать виртуальные сервера на другую площадку. Не лучшее решение, но вроде сойдет.
Однажды наш ЦОД действительно потерял внешнее питание, и мы узнали, что кондиционеры не были подключены к ИБП. Машзалы мгновенно перегрелись, и через полчаса все системы начали отключаться.

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

Мы – клиенты крупного ЦОДа, все резервировано – питание от батарей, дизели, дублированная оптика с разными трассами – идиллия. Машинные залы расширяли, и бравые парни выломали пару стен, предварительно отгородив оборудование от пыли. Потом этим двум клоунам пришла в голову гениальная идея помыть пол в зале. К несчастью, они выбрали ведро с водой и тряпку как в старые добрые времена. Разумеется, один из них нечаянно перевернул ведро.


В комментариях пишите о своих авариях класса «вопреки резервированию».
Поделиться публикацией

Похожие публикации

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

    +1
    > Однажды наш ЦОД действительно потерял внешнее питание, и мы узнали, что кондиционеры не были подключены к ИБП. Машзалы мгновенно перегрелись, и через полчаса все системы начали отключаться.

    У нас такая же фигня в одной серверной была. Питание резервировано очень мощными ИБП, хватало где-то на час или даже больше. А вот кондеры забыли зарезервировать. В итоге половина техники отключилась через полчаса, а вторая половина техники продолжила работать, но «сошла с ума»: кто стал сыпать ошибками, кто перешел в третье состояние и не поддавался перезагрузке удаленно. В общем весело было.
      +2
      Но около 6 утра эскаватор перерубил шедшую через континент оптику.
      Только хотел написать о правиле экскаватора, но бравые австралийцы меня опередили
        0
        Если память не изменяет, относительно недавно, года 3-5 назад. Ещё и подводный кабель рвали, то ли рыбаки, то ли нефтяники.
        +1
        Знаю я и в России случаи, когда ЦОД дерьмом залило. Потом с инженерами этого ЦОДа все корректно отказывались за руку в этот день здороваться.
          +3
          А в ЦОД было несколько других приколов. В нем используется воздушное охлаждение, но теплоотвод осуществляется в частности при помощи здоровенных холодильников с использование гликоля. В новогодние праздники один из холодильников дал течь и вышел из строя. Автоматика почему-то это не заметила. В итоге когда проверяющий инженер во время обхода заметил протечку, а прошло уже около 6 часов, в машинном зале температура была 55+ градусов.

          Еще было весело с контроллером, который следит за насосами для этих холодильников. Это простой ПЛМ с небольшой мозгой и вебмордой, торчащей во внутренней сети. Эта штука всего одна на все насосы. Сбой насоса считается критическим и приводит к аварийной остановке всего ЦОДа в течении 5 минут. Так вот, оказалось что для этой штуки существует свой пакет-убийца, который при внезапном попадании вызывает сброс контроллера, который при этом тут же сообщает выше, что всем насосам кирдык и в итоге весь ЦОД мгновенно складывается. То, что это именно эта железка виновата сообразили далеко не сразу…
            +7
            Когда американцы проектировали АЭС они учли всё. В случае землетрясения останавливаются турбоагрегаты — основной источник питания циркуляционных насосов и они запитываются от дизеля. Надежно? Вроде да. Вот только после землетрясения прошло цунами (вызванное опять-таки землетрясением), затопившее дизельгенератор, отвечающий за питание цирк. насосов.
            Думаю, все уже поняли, что речь о Фукусиме.
            Согласен, что к IT относится слабо, но опыт тоже полезный.
            * На правах истории, рассказанной мне преподавателем после аварии.
              +1
              Простите, но что именно учли проектировщики построив АЭС с основанием ниже уровня моря? Да еще и на берегу моря.
                0
                Если бы ДГУ установили на платформу выше уровня цунами, то дизель бы не остановился и циркуляция в реакторной зоне продолжалась бы.
                  0
                  Цунами несет гораздо больше энергии, чем обычные штормовые волны той-же высоты, по этому конструкция, которая рассчитывалась на 10 метровые штормовые волны скорее всего не выдержит аналогичной по высоте волны цунами.
                  Следовательно подъем платформы с дизелями сводится к вопросу о том, как можно было строить АЭС, основание которой ниже уровня моря.
                  Не забывайте еще учесть, какие повреждения нанесло цунами электрике и трубопроводам станции. Мы видим только самую очевидную проблему: нет дизелей->нет электричества->нет циркуляции воды, но кто знает была ли возможность охлаждать при наличии электричества? Насколько были живы насосы и трубопроводы? Этого мы не знаем.

                  Прочность цепи не может быть выше прочности самого слабого звена, по этому совершив очевидный ляп по строительству АЭС ниже уровня моря на самом берегу рассуждать об остальных системах не имеет смысла. Если бы АЭС была выше или дальше от берега, то она прекрасно бы работала и дальше даже после цунами.
              +7
              Нет ничего абсолютно надёжного =) Стоит всё задублировать — прилетит метеорит :)
                +2
                Угу.

                У нас на складе до сих пор валяется шасси cat6509, которое затопило в подвале :)
                И дизель, питавший наш офис, один раз не завелся. Дело было этим летом, с утра, и всех, кому не требуется сидеть на рабочем месте и у кого есть VPN, распустили по домам — ибо ИБП есть на много часов, но кондиционеры сразу умерли, а окна в БЦ принципиально не открываются, и уже через 10 минут работать стало совсем невыносимо. Хоть в серверных помещениях кондиционеры продолжали работать…
                И один из наших ЦОДов года 4 назад ложился часов на 6 по питанию.
                И падения двух совершенно независимых каналов от двух разных операторов до одной важной региональной площадки были (с интервалом в полчаса).
                И внезапно выяснялось, что некая система, адски важная и подключенная к двум разным выделенным каналам, на самом деле имела связь лишь с одним из них, а резерв администраторы за долгие годы так и не удосужились проверить.

                Эх…
                  +2
                  Но ведь есть бумага, которая побеждает камень (здесь должна быть картинка)
                +3
                Raid10, но диски одной партии(даже серийники почти по порядку).
                В результате они оказались очень похожими.
                В общем, механически сдохли 3/4 с интервалом 15 минут.
                  +2
                  Ага, похожая ерунда была. Еще и диски оказались из проблемной серии Seagate, причем все!
                    +2
                    О как мне это знакомо! 4 диска 1Tb Seagate померли буквально за две недели
                      +1
                      Тут не в том прикол, что мало проработали, как я понял :D А в том, что диски настолько идентичны, что даже умерли в 1 день с интервалом в 15 мин :<
                        +1
                        ну да, у меня они проработали 4 года перед смертью, жили долго и счастливо и умерли в две недели, теперь я зарекся ставить диски из одной партии в одну машину
                  +1
                  Одна знакомая контора (украинская) все, казалось бы сделала правильно — рабочий сервер, и резервный сервер, бекапы — на отдельном сервере. Но все это было у одного хостера, в одном ЦОДе. И там случился пожар… Не помню точно, как назывался тот хостер, но наверняка кто-то из хабровцев помнит эту историю.

                  Базу потом восстанавливали из той, что скачали к себе в локалку для тестирования новой версии софта.
                    +1
                    Если не ошибаюсь было жарким летом 2010, я пользовался услугами хостинга и сервис был недоступен около 2х недель, а хостинг назвался «хостия», пожар был по причине электропитания
                      +1
                      imhost?
                        0
                        hostia
                          0
                          может «хостя» у «хостинг.уа» хостится? :)
                            0
                            Возможно :)
                        0
                        Hosting.ua
                        В комментах даже пару фотографий есть.
                          0
                          Значит на Украине горело два хостинга :)
                        +1
                        Статья написана в духе «что ни делай, а всё равно произойдет две лажы подряд и всё сломается». Но ведь в 99% случаев случается лишь одна лажа в один момент времени и тут уж любой резерв пригодится.
                          +1
                          Вам нужна надежность? Нет? Ну тогда можете обойтись простыми способами резервирования, не предполагающими катастрофоустойчивости и допускающими надежность на те самые две девятки :)
                          Кому-то ведь действительно этого хватает. Ну упадет инфраструктура на пару часов — ничего страшного.
                          А кому-то минута простоя одного участка — серьезная проблема.
                            –2
                            Это понятное дело. Просто от статьи веет безысходностью и детерминизмом. Мол, «и нафига было вообще стараться, если вот такие двойные беды бывают». Стараться всё-равно надо, и чем больше, тем лучше. А статья подбивает только руки опустить и молиться случаю.
                              +1
                              Эта статья — из цикла «как делать не надо» или «о чем нужно помнить»
                                +1
                                Нет. Именно что статья подбивает строить сервис так, чтобы при падении крупного метеорита на любой из хостящих его ЦОДов сервис продолжил работу с минимальным простоем. И нельзя исходить из того, что вроде бы на первый взгляд не связанные друг с другом компоненты, резервирующие друг друга, не могут отказать одновременно.
                                  +2
                                  Не совсем. Статья начиналась с того, что каждый компонент должен разрабатываться с требованием надежности, а не надеяться на надежность нижележайших уровней.
                                    +1
                                    а по мне, статья очень веселая! =) И понятно, что описаны редкие случаи, ясное дело обычно не происходит «сразу всё».
                                +8
                                Кстати, по поводу отличной от нуля вероятности и SLA. Вот о таких цифрах мы никогда не задумываемся, но что если простой стоит $50к в час, то от девяток много что зависит. Вот такой слайд я видел на конференции Cloud Connect:
                                  0
                                  Ну да, $44K. Но переживать сильно не стоит, т.к. это всего лишь 0.01%.
                                    0
                                    Кто даёт такие девятки из провайдеров? Обычно один десятичный знак.
                                    +7
                                    Тут надо еще один слайд для объективности — показывающий стоимость правильного обеспечения этих девяток, который растет экспененциально вверх :)
                                    +7
                                    вчера экскаватор перебил 4 оптики в канализации. По иронии судьбы работали без согласований, без ордеров и яма аккурат под огромным желтым щитом, на котором красными большими буквами написано. ЗДЕСЬ КОПАТЬ ЗАПРЕЩЕНО.
                                      +5
                                      Обратная ситуация:
                                      Небольшая серверная небольшого провайдера, питание резервировано UPS и генераторами, все корректно отрабатывает, упсы перехватывают, генераторы заводятся, кондиционеры работают. Вот только работающие маршрутизаторы, бесперебойная связь и продолжающее выдавать прекрасную картинку оборудование головной станции КТВ никому не нужно — обесточен весь район обслуживания. Погасили все и пошли по домам.
                                        +1
                                        И это все от недостатка тестирования… но с другой стороны как его осуществлять?)
                                          +3
                                          В идеале нужно имитировать катастрофы всех родов с высокой регулярностью.
                                            0
                                            Периодически небольшие ядерные бомбы взрывать над датацентром? ООН же будет негодовать.
                                              +2
                                              Можно куда проще — запускать охранника с чайником в гермозону и разрешать ему делать что угодно. Если система выживает — значит следующим циклом идёт уборщица.
                                          +4
                                          Еще один случай из классики жанра:

                                          royal.pingdom.com/2007/11/13/truck-takes-down-rackspace/

                                          В 2007 году грузовик въезжает в подстанцию, и выносит питание ЦОДу Rackspace — ага, вот те ребята (с) с 100% аптаймом по их рекламе. Бэкапное питание завелось, а два кондиционера — нет. Было выключено довольно много серверов, которым светил перегрев, включая 37signals, а так же сервер вашего покорного, на котором крутился софт медицинского назначения. Крику было… RS потом две недели сочиняла извинения.

                                          Ну и давний эпик из Германии (sic!). Не помню точно год, где-то 2003 — но полстраны как-то утром осталась без Интернета. Пьяный экскаваторщик перерубил магистральную оптику под Франкфуртом — просто вот так, несмотря на кучу предупреждений аля «не копать — кабЕль». И это при местной рабочей культуре, которая без команды обычно чихнуть не смеет, т.е. проверять перед копанием — как бы само собой. Доступ появился только после обеда.
                                            0
                                            100% гарантия SLA Rackspace в рекламе означает что за любой прокол компания отвечает и оплатит издержки.

                                            100% uptime, к сожалению, не возможен даже у Rackspace, максимум – много девяток после запятой. Я тоже по началу удивился, но потом понял что там не uptime, а SLA.
                                              0
                                              Ну это да — но рекламщики такие рекламщики :)
                                              0
                                              Пьяный экскаваторщик

                                              Вот, собственно, и объяснение, почему несмотря не все предупреждения и культуру…
                                              –21
                                              Вчера отключили электиричество, но angri birds всеравно работает на айпаде. :) 4 часа, полет нормальный. По одному айпаду на каждого члена семьи. + два вайфай-3г маршрутизатора разных производителей, htc и nokia. Бюджет системы менее 100к рублей.
                                                +1
                                                Здание, не ЦОД, и все его основные BMS, включая серверную комнату запитаны по 1 категории, т.е. 2 различных ввода + ИБП для серверной и дизель на пол мегаватта для основных BMS, в серверной комнате 1 центральный прецизионный кондиционер и 2 резервных тоже прецизионники, но меньшего размера — центральный по 1 категории, резервные дополнительно еще и на ИБП.

                                                Где-то в районе 3-х часов утра выключается 1 линия, все сотрудники ИТ получили уведомление в виде смс о падении одной линии питания, инженеры-электрики (но не ИТ) вызваны на место, но не успевают доехать, через полчаса после первой падает вторая линия, снова уведомление в виде смс, срабатывают ИБП, все основные системы продолжают нормально работать, за исключением внешних блоков резервных кондиционеров. Во время переключения на ИБП по какой-то причине внешние блоки кондиционеров перезапустились, в результате этого перезапуска оказалось достаточно для того, что бы управляющие блоки обоих резервных кондиционеров сошли с ума и потеряли связь с внешними блоками, а восстановить связь автоматически им не удалось. В виду того, что серверная вместе с кондиционерами должна была проработать минимум 6 часов, то ИТ не вызывали. Доступ в серверную комнату, как в помещение особого назначения есть только у ИТ, так что никто в нее не заходил и не проверял состояние систем. Вобщем через 2 часа после уведомления о переходе на ИБП посыпались уведомления о принудительном выключении оборудования по перегреву.

                                                Первая линия электропитания выключилась из-за аварии на подстанции, вторая линия — золотое правило экскаватора, возможно даже и авария на подстанции связана с экскаватором.
                                                  +1
                                                  У нас все было сделано как положено, кондиционирование тоже было с запасом, но тут наступает весна, тополи просыпаются и… в понедельник я прихожу, берусь за металлическую ручку деревянной двери ЦОД и отскакиваю — температура ручки — порядка 60 градусов. Заскочив в эту духовку, я обнаружил что рубашка моментально разогрелась и горячая, к стойкам больно прикасаться, оборудование почти все выдержало, сдохла пара БП в серверах, благо, второй БП перехватил, но поповина оборудования весело моргала огоньками и висела. Остывал ЦОД почти 6 часов при проточной вентиляции.
                                                    +4
                                                    У вас было сделано не так уж и как положено, если вы узнали о перегреве только когда обожглись…
                                                      0
                                                      Согласен, но серверная была маленькая и бюджетная (чуть больше 30 серверов). Удивительно, что вообще было то, что было.
                                                        0
                                                        Ну блин Нагиос или Заббикс в виртуальную машину можно поставить для мониторинга даже пары серверов (собственно я так и делал).
                                                          0
                                                          Даже встроенный софт наверняка умеет отправлять емейлы о факапах, будь то вылет винта или перегрев.

                                                          Хотя лучше, конечно, ставить внешние датчики температуры, влажности, шума и так далее.
                                                            0
                                                            Бессмысленно — дело в том, что в нерабочее время в здание попасть было невозможно, а в рабочее мониторинг работал, целых две системы постоянно мониторили все сервисы и уведомления были настроены ответственным инженерам и мне. Поэтому, о том, что там проблемы с доступностью сервисов я знал еще в выходные, но что-то делать было бесполезно — все равно в серверную до понедельника не попасть.
                                                              0
                                                              Это где такой цирк твориться, что в аварийной ситуации, которая может привести минимум к выходу из строя оборудования, а как максимум к пожару персонал не допускается для ее ликвидации?

                                                              В любой нормальной организации даже с повышенными мерами безопасности есть регламент на доступ определенного персонала в определенные помещения в круглосуточном режиме. Охрана конечно будет не сильно рада такой радости, но раз регламент есть, то будут его выполнять.
                                                                0
                                                                Здание Юниаструм банка на углу Селезневской и Суворовской площади.
                                                                Дело в том, что в том же здании находится Импромашпром — те самые, что ракетами занимались. Режимный объект. Им похер на все пожарные требования — на проходной стоит часовой с автоматом.
                                                                  0
                                                                  Значит пока гром не грянет…

                                                                  А про автоматчиков, ведь хотел же я написать, что ситуации, когда работы на объекте во вне рабочее время проводятся только в присутствии пары автоматчиков вполне реальны, но подумал, что это лишнее :)… Так что часовой с автоматом ничего не говорит об уровне общего бардака.
                                                                    0
                                                                    Наверное, я там давно уже не работаю :) Так что меня этот бардак не касается )
                                                      0
                                                      Резервирование делается для защиты от штатных отказов и аварий.
                                                      В случае катастрофы поможет только грамотно разработанный процесс Disaster Recovery. Поможет быстро восстановиться после катастрофы, а не защититься.
                                                        –1
                                                        Случай из жизни.

                                                        Резервировалась база SQL Server.
                                                        Сначала на другой логический диск, потом записывалась на DVD-RW болванку.
                                                        Во время перезаписи текущей болванки накрывается физически жесткий диск,
                                                        +система рестартует.
                                                        База непоправимо уничтожена.
                                                        Последний и предпоследний бэкап на DVD-RW уничтожены.

                                                        Зато теперь 3 копии, на разнесенных серверах.
                                                        Полный бэкап+Разностный бэкап+бэкап trasaction log. )))

                                                        Если бы мне рассказали — не поверил бы. ))
                                                          0
                                                          А зря не поверили бы ) Дело в том, что когда что-то начинает ломаться, по определению все остальное оборудование работает в режиме повышенной нагрузки, а это существенно повышает шанс выхода из строя. Именно поэтому Backup сервер обычно отдельно стоящий, он принимает снимок, а потом уже пишет его спокойненько на ленту или болванку или куда там вы запланировали.
                                                            +1
                                                            Не всегда директор понимает фразу «отдельно стоящий Backup сервер» ))
                                                              +1
                                                              Ага, часто после первого невосстановимого бекапа только начинает понимать…
                                                                0
                                                                Угу, после переезда в новый офис, с большой серверной, файловый сервак с RAID5 из 10 дисков таки упал по вине контроллера (тот самый сервер, что пережил перегрев ранее), после этого ген.дир пришел и сказал (дословно):«что тебе нужно, чтобы такого больше не повторилось?» И выделил деньги на то оборудование, что я порекомендовал.
                                                                  +1
                                                                  Ну, а бывает и по другму — до сих пор помню свой первый выговор, на заре админской карьеры, после невосстановимого бекапа и моего замечания, (мол, «а я же предупреждал что нужно отдельное железо») — деректор выдал перл «ну ты же спциалист, надо было НАСТОЯТЬ на своём». :)
                                                                    0
                                                                    И, как это ни обидно, в некотором смысле он был прав )
                                                                    другой вопрос, что этому нигде не обучают, никогда об этом не предупреждают и тп. Но если нам отказывают, то желательно доводить до сведения того, кто подписывает отказ в письменной форме чем это грозит.
                                                                    Если человек пишет — ок, с риском согласен, то тогда уже он будет неправ.
                                                                      0
                                                                      Ну, теперь то я все это понимаю. Но в маленьких конторах все по другому, бумажками никто не заморачивается…
                                                                        0
                                                                        На самом деле зависит от конторы, но чаще да, не заморачиваются. А вообще довольно быстро вводится письменное уведомление даже в офисе из 4х человек, мы такое практиковали в 2003м. Тогда если кто-то забыл или делает вид что забыл, то ему легко напомнить письмом :)
                                                                0
                                                                Прекрасно понимаю, я выделил под него сервер, который не тянул свою нагрузку, официально был устаревший, а для бэкапа много не нужно. К тому же отдельно стоящим он должен быть от сервера, который бэкапит. Главное, чтобы он не был нагружен под завязку дисковыми и вычислительными операциями. Совмещать никто не запрещает. Но то, что работает на нем, должно бэкапиться на другой сервер. Это усложняет поддержку, но если денег на отдельный сервер нет, то лучше так.
                                                            +2
                                                            У нас в EDU все было резервировано. Но вот одно мы исправить не могли. Машинный зал находился прямо под туалетом художественного отдела. В общем, однажды нас натурально затопило говном. А вы знали, что можно заказать у Sun Microsystems выезд их бойцов для протирки оборудования СХД ватными тампонами со спиртом?

                                                            Вот это просто бесценно :D Представляю себе «радость» бойцов Сан, когда они приехали «протирать оборудование спиртом» после такого :D Серверную затопило говном дизайнеров… хмм, знакомо! :D
                                                              +9
                                                              Для русского человека тут есть и еще одна хохма. «SUNтехники приехали».
                                                                0
                                                                :D не подметил этого, brilliant!
                                                              +1
                                                              Пара случаев из моей жизни:

                                                              1. Две линии питания, с разных подстанций. Сводятся, разумеется, в одном релейном шкафу. Ночной охранник поставил на шкаф чайник с водой и опрокинул его.

                                                              2. ДЦ с двумя каналами выхода в инет, от двух разных провайдеров, выводы с разных сторон здания. Как оказалось позднее, чрез километр экономные провайдеры решили объединить усилия и потянули кабели вместе. Не в канализации, по воздуху. Упавшее во время шторма дерево накрыло оба кабеля.

                                                              Сколько не резервируй, где-то за стенами будет SPOF, и метеорит прилетит именно туда.
                                                                +1
                                                                Ночной охранник имеющий доступ к шкафу ввода электричества?
                                                                  +2
                                                                  Ну не сам он, а вода из его чайника.
                                                                    +1
                                                                    Обычно и сам машинный зал, и все вспомогательные объекты (ИБПшная и так далее) — те места, к которым охранник даже приближаться не может. В крайнем случае — в сопровождении дежурного инженера. Так что действительно странно.
                                                                      0
                                                                      Странно или нет. В РНД есть (или был) один такой провайдер, у которого весь город отрубило. Так вот один мой знакомый работал как раз дежурным инженером. И был дежурный электрик, который должен был следить ночью за энергообеспечением здания. Но и электрик был спросони, и инженер не сильно вкуривал в OVER 9000 рубильников. Сначала грохнули основное питание. Потом грохнули аварийное. Ну проработали маршрутизаторы порядка часа на ИБП. А потом и весь дневной состав приехал разбираться что случилось, и ночной. Чем для электрика история закончилась так и не узнал, было это давно и не правда.
                                                                0
                                                                Тоже наблюдал странные вещи.
                                                                У меня в квартире стоит стабилизатор на входе, вся техника подключена в сетевые фильтры, все заземлено — все как положено. И вот полетел не самый дешевый БП FSP через 2,5 года использования, унеся за собой винт Seagate с кучей ценной информации.
                                                                А у знакомого в деревне без заземления, с мигающими от перепадов лампочками стоит китайский Codegen, который даже по заявленной мощности не соответствует компонентам ПК — и подключен в уже оплавленную розетку. На мои возгласы «чуваак, выкинь эту штуку, тебе нужно купить нормальный БП!» он ответил: «Да ладно, я его в 2004 купил и все работает. Зачем что-то менять?».

                                                                Тут-то я и задумался…
                                                                  0
                                                                  Аппаратный Adaptec RAID 1 с батарейкой в состоянии «optimal» :) Сервер не перегружался… Суперблок на ext3 пропал, fsck по резервной копии супер-блока никак не помог, некоторые каталоги оказались в бесконечном цикле :)

                                                                  До этого сервер проработал год без перезагрузки и каких-либо проблем…

                                                                  Вобщем мистика в чистом виде… «НЛО прилетело и украло ваш суперблок»…
                                                                    0
                                                                    Половину всех аварий можно было избежать проводя периодические учения и испытания разных сценариев отказа.
                                                                      0
                                                                      У нас тоже как-то накрылся европейский ЦОД во время грозы. Сначала выбило молнией подстанцию и ЦОД начал переключаться на генераторы, а следующий удар молнии накрыл цепи генераторов. Переключение на резервный ЦОД произошло с ошибками в результате чего всю сеть колбасило несколько часов…

                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                      Самое читаемое