Планирование аварийного восстановления Windows Server 2003 (часть 1)

Опубликовано: 14 Апреля, 2023

Чтобы получить полное руководство по безопасности, ознакомьтесь с « Учебным пособием по безопасности + и DVD-системой обучения » на Amazon.com.

Планирование высокой доступности

Планирование аварийного восстановления Windows Server может быть рутинной работой, но если у вас есть детали и план, установка может пройти гладко и станет спасением жизни, когда ваши системы начнут дымить, а ваши вице-президенты постучат в дверь вашего офиса и спросят. Что же такое происходит! В этом разделе мы рассмотрим, как планировать высокую доступность.

Уделите время планированию и проектированию — это ключ к вашему успеху, и это касается не только дизайна, но и усилий, которые вы вкладываете в изучение. Я всегда шучу со своими администраторами и говорю им, что они доктора технических наук. Я говорю: «Когда вы становитесь врачом, вы должны быть профессионалом и поддерживать этот профессионализм за счет роста образования путем постоянного обучения и совершенствования своих навыков». Многие ИТ-специалисты думают, что их работа — с 9 до 17, без учебы в нерабочее время. У меня есть для них одно слово: неправильно! Вы должны относиться к своей профессии, как если бы вы были высококвалифицированным хирургом, за исключением того, что вы работаете не с человеческой жизнью, а с технологией. Вот как нужно подходить к планированию решений высокой доступности. Вы не можете просто крылать и не можете догадаться об этом. Вы должны быть точны, иначе ваши вложения пропадут даром — и вся проделанная вами работа будет не только бесполезной, но и расточительной.

Планируйте время простоя

Вам необходимо достичь как можно более близкого к 100-процентному времени безотказной работы. Однако вы знаете, что 100-процентное время безотказной работы нереально и никогда не может быть гарантировано. Поломки происходят из-за сбоев диска, отказа питания или ИБП, проблем с приложениями, приводящих к сбоям системы, или любых других аппаратных или программных сбоев. Таким образом, следующий лучший результат — 99,999%, что все еще разумно с сегодняшними технологиями. Вы также можете определить в соглашении об уровне обслуживания (SLA), что означает 99,999% для обеих сторон. Если вы пообещали кому-то 99,999% времени безотказной работы в течение одного года, это означает, что коэффициент простоя составляет от пяти до десяти минут. Я бы стремился к большему количеству, которое более реалистично для запланированных отключений и возможного тестирования аварийного восстановления, выполняемого вашим персоналом. Добейтесь 99,9% времени безотказной работы, что означает от девяти до десяти часов простоя в год. Это более практично и возможно получить. Предоставляя или получая такую услугу, обе стороны должны протестировать запланированные отключения, чтобы убедиться, что графики доставки могут быть соблюдены. Вы можете вычислить эту формулу, взяв количество часов в дне (24) и умножив его на количество дней в году (365). Это равняется 8760 часам в году. Используйте следующее уравнение: процент времени безотказной работы в год = (8 760 – общее количество часов простоя в год) / 8 760. Если вы запланировали восемь часов простоя в месяц на техническое обслуживание и простои (всего 96 часов), то вы можете определить процент время безотказной работы в год составляет 8760 минус 96 деленное на 8760. Вы можете видеть, что вы получите около 98,9% времени безотказной работы ваших систем. Это должен быть простой способ обеспечить точный учет времени простоя. Помните, что при планировании высокой доступности необходимо точно учитывать время простоя. Время простоя может быть запланированным или, что еще хуже, неожиданным. Источники непредвиденных простоев включают следующее:

Сбой или сбой диска
Сбой питания или ИБП
Проблемы с приложениями, приводящие к сбоям системы
Любая другая аппаратная или программная неисправность

Построение плана высокодоступных решений

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

Компания использует сервер для доступа к приложению, которое принимает заказы и выполняет транзакции.
Приложение, когда оно запущено, обслуживает не только сотрудников отдела продаж, но и еще три компании, осуществляющие B2B-транзакции. По оценкам, в течение одного часа максимально заработанные деньги превысили 2,5 миллиона долларов.
Сервер выходит из строя, и у вас нет решения высокой доступности. Это означает, что аварийное переключение, избыточность или балансировка нагрузки вообще отсутствуют. Это просто терпит неудачу.
Вам (системному инженеру) требуется 5 минут, чтобы вызвать пейджинг, но около 15 минут, чтобы добраться до места. Затем вы тратите 40 минут на устранение неполадок и решение проблемы.
Сервер компании возвращается в оперативный режим, и соединения восстанавливаются.

Все снова кажется функциональным. На этот раз проблема была проста — простой сбой приложения, из-за которого служба останавливалась, а после перезапуска все было в порядке. Теперь проблема со всем этим сценарием заключается в следующем: хотя это была настоящая катастрофа, она была также и простой. Системный инженер оказался рядом и смог довольно быстро диагностировать проблему. Даже лучше, проблема была простым решением. Эта простая проблема по-прежнему приводила к отключению общего приложения компаний как минимум на один час, и, если бы это был пиковый период времени, можно было бы потерять более 2 миллионов долларов. Они хотят быть в курсе, поэтому вероятность того, что 2 миллиона продаж испарятся, больше никогда не возникнет. Что еще хуже, компании, с которыми вы связываетесь, и ваша собственная клиентура начинают терять веру в вашу способность их обслуживать. Это также может стоить вам дохода и возможности приобретения новых клиентов в будущем. Люди болтают, и необразованные люди могут воспринять этот небольшой сбой как серьезную проблему с людьми вашей компании, а не с технологиями. Давайте еще раз посмотрим на этот сценарий, но уже с использованием высокодоступного решения:

Компания использует сервер для доступа к приложению, которое принимает заказы и выполняет транзакции.
Приложение, когда оно запущено, обслуживает не только сотрудников отдела продаж, но и еще три компании, осуществляющие B2B-транзакции. По оценкам, в течение одного часа максимально заработанные деньги превысили 2,5 миллиона долларов.
Сервер выходит из строя, но у вас есть высокодоступное решение. (Обратите внимание, на данном этапе не имеет значения, какое решение. Важно то, что вы добавили избыточность в службу.)
Сервер и приложение являются избыточными, поэтому, когда происходит сбой, избыточность защищает приложение от сбоя.
Клиенты не затронуты. Бизнес возобновляется в обычном режиме. Ничего не теряется и время простоя не накапливается.
«Один час», который вы сэкономили своему бизнесу во время простоя, оплатил все внедренное вами высокодоступное решение.

Человеческие ресурсы и высокодоступные решения

Человеческие ресурсы (люди) должны быть обучены и работать на месте, чтобы справиться со стихийным бедствием. Они также должны знать, как работать под огнем. Как бывший морской пехотинец Соединенных Штатов, я знаю о «тумане войны», когда вы чувствуете себя уставшим, дезориентированным и, вероятно, не сосредоточенным на работе. Эти характеристики не помогают вашему времени ответа с руководством. В любой организации, особенно с такой сложной системой, как высокодоступная, вам нужны правильные люди для ее запуска.

Управление вашими услугами

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

<> Управление услугами — это управление истинными компонентами высокой

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

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

Идеи высокодоступной оценки системы

Ниже приведен список элементов, которые вы можете использовать на этапе постпродакшн-планирования. Убедитесь, что вы охватили все свои базы этим списком:

Теперь, когда вы настроили свое решение, задокументируйте его! Отсутствие документации наверняка обернется для вас катастрофой. Документировать не сложно, это просто утомительно, но вся эта работа в конце концов окупится, если она вам понадобится.
Обучите свой персонал. Убедитесь, что у ваших сотрудников есть доступ к тестовой лаборатории, книгам для чтения и курсам повышения квалификации. Посетите бесплатные семинары, чтобы узнать больше о High Availability. Если вы можете игнорировать коммерческие предложения, они весьма информативны.
Проверьте свой персонал с помощью учений по реагированию на инциденты и сценариев стихийных бедствий. Письменные процедуры важны, но живые учения еще лучше, чтобы увидеть, как ваши сотрудники реагируют. Помните, что если у вас произошел сбой в системе, она может переключиться на другую систему, но вы должны быстро решить проблему на первой системе, в которой произошел сбой. У вас может быть такая же проблема на других узлах в вашем кластере, и если это так, у вас мало времени. Создайте сценарий и протестируйте его.
Оцените текущий бизнес-климат, чтобы всегда знать, что ожидается от ваших систем. Планируйте будущую емкость, особенно по мере добавления новых приложений, а также по мере увеличения оборудования и трафика.
Пересмотрите свои общие бизнес-цели и задачи. Убедитесь, что то, что вы собираетесь делать с вашим решением высокой доступности, предоставляется. Если вы хотите более быстрый доступ к системам, действительно ли это быстрее? Когда у вас возникает проблема, происходит ли аварийное переключение без проблем? Пострадают ли клиенты? Вы же не хотите внедрить решение высокой доступности и снизить производительность. Это не будет выглядеть хорошо для вас!

Проведите анализ потока данных в соединениях, которые использует высокая доступность. Вы будете удивлены тем, что поврежденные сетевые карты, неправильные драйверы, избыточные протоколы, узкие места, несоответствие скоростей портов и дуплексный режим, и это лишь некоторые из проблем в системе. Я добился существенных изменений в сетях, просто проведя анализ потока данных в проводной сети, и благодаря этому анализу получил большие различия в скорости. Хорошим примером может быть, если у вас были старые сетевые карты на основе ISA, которые работали только со скоростью 10 Мбит/с. Если вы подключили свою систему к порту, который использует 100 Мбит/с, то вы будете работать только со скоростью 10, потому что это так быстро, как может работать сетевая карта. Что произойдет, если порт коммутатора будет настроен на 100 Мбит/с, а не на автоматическое согласование? Это создало бы проблему, поскольку сетевая карта не могла бы обмениваться данными по сети из-за несоответствия скоростей. Подобные проблемы распространены в сетях и вполне могут быть причиной плохого потока данных в вашей сети или его отсутствия.

Контролируйте службы, которые вы считаете важными для работы, и следите за тем, чтобы они всегда работали. Никогда не думайте, что система будет работать безупречно, пока не будут внесены изменения... иногда системы задыхаются сами по себе либо из-за зависшего потока, либо из-за процесса. Вы можете использовать инструменты мониторинга сети, такие как GFI, Tivoli, NetIQ или программные решения Argent, для мониторинга таких служб.
Оцените общую стоимость владения (TCO) и посмотрите, стоило ли оно того.

Анализ затрат

Проведите окончательный анализ затрат, чтобы убедиться, что вы приняли правильное решение. Лучший способ определить совокупную стоимость владения — это воспользоваться онлайн-калькулятором совокупной стоимости владения, который покажет вам совокупную стоимость владения на основе вашей собственной уникальной бизнес-модели. Поскольку, по большей части, все бизнес-модели будут разными, лучший способ определить совокупную стоимость владения — запустить калькулятор и рассчитать совокупную стоимость владения на основе ваших личных ответов на вопросы калькулятора. Вот пример конкретного, но многие другие доступны для использования в Интернете — просто запустите поиск в поисковой системе (например, Google.com) по калькуляторам ROI/TCO, и вы их увидите.

Тестирование системы высокой доступности

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

В сумме

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

Кибер-безопасность