У нас есть веб-приложение, размещенное на внутренней виртуальной машине Windows. У нашей компании есть несколько баз по всей стране, каждая со своей серверной стойкой, а базовые локальные сети связаны друг с другом в большую интрасеть.
В настоящее время это приложение размещено на сервере в штаб-квартире, но сегодня у него отключили электричество. Энергетическая компания запланировала это несколько недель назад и уведомила нас, подсунув под дверь листок бумаги. Но страна находится в изоляции от Covid19, поэтому ИТ-подрядчики узнали об этом примерно за час до его начала. Впервые я (ведущий разработчик этого приложения) услышал об этом через час после отключения, когда у ИБП оставался час автономной работы. Подрядчику удалось передать виртуальную машину другому серверу на другой базе (которая в любом случае принимает резервные копии, поэтому было относительно просто запустить еще один моментальный снимок до того, как батареи разрядятся, и запустить виртуальную машину на другой базе).
В любом случае, хотя я был очень доволен, что они смогли передать его так быстро (включая каким-то образом Интернет, обращенный к имени хоста), мы не делали этого по-настоящему раньше, и я не ожидал, что это сработает.
У меня возникает вопрос, как лучше всего иметь два экземпляра приложения, работающие на двух отдельных серверах, которые находятся в одной интрасети, но имеют свои собственные независимые интернет-соединения и имеют возможность переключения имени хоста на альтернативный сервер на случай, если первичный выход из строя? Если обратный прокси - это ответ, куда мы его поместим? Потому что это новый сбой единой точки, не так ли? Он должен учитывать возможность того, что любой сервер и вся его база потемнеют, как это случилось с нами сегодня.
Синхронизация основной / альтернативной баз данных - это проблема, которую легко решить, наши ребята справятся с этим.
Если вы все просто хотите кричать ВМЕСТО ХОЗЯЙСТВА, это нормально, мне тоже это нравится. Мне пока не удалось убедить руководство, что это хорошая идея. Они думают что-то о праве собственности на данные. Неважно, что множество сторонних систем, которые они используют с такими же конфиденциальными данными, размещены в облаке.
Наконец, я не специалист по инфраструктуре, мозги, стоящие за ИТ-отделом компании, ушли несколько месяцев назад, а ИТ-подрядчики не имеют большого отношения к инфраструктуре высокой доступности. Я надеюсь использовать это мероприятие, чтобы добиться реальных положительных улучшений.
Вам нужен план обеспечения непрерывности бизнеса, адаптированный к потребностям вашей организации. Общий объем этого намного превышает один вопрос, на самом деле он должен информировать всю организацию, а не только ИТ.
Начните с того, что спросите организацию, сколько незапланированных простоев допустимо для уровней обслуживания вашего приложения. Возможно, это приложение очень важно, и его цель - менее 60 минут в год, время безотказной работы 99,98%. Используйте эти цели обслуживания для разработки дизайна высокой доступности.
Просмотрите незапланированные простои и определите основную причину каждого из них. Также проведите мозговой штурм над вероятными угрозами, которые еще не стали проблемой. Это ваши риски. Сбои в работе сети, включая поставщиков услуг, питание, заражение вредоносным ПО, отказ оборудования, программный сбой, человеческие ошибки и т. Д.
Возьми власть. Одна вещь, которую эта близкая неудача подчеркнула, - это важность общения с энергетической компанией. Определите более надежные процедуры для запланированных событий. Возможно, список адресов электронной почты включает ИТ-подрядчиков, электриков и сотрудников центра обработки данных.
Кроме того, генераторы позволяют работать без электросети. Предоставьте возможность установить генераторы, иметь достаточно аккумуляторов для отключения, поддерживать договор на заправку и регулярно проверять их запуск. Возможно, добавить вторичную мощность с собственным подключением к сети, батареями, генератором и распределением. Дорого, но, возможно, время простоя тоже обходится дорого.
Еще один забавный режим сбоя питания: электрические пожары. Скажем, дым в центре обработки данных вызывает аварийное отключение питания. После того, как пожарная команда вернет вас обратно, у вас будет процедура включения центра обработки данных? Сколько времени это занимает? Было ли это когда-нибудь проверено?
Загорелся первичный центр обработки данных - отличный повод запустить его на другом сайте. Ваше запланированное переключение позволило сделать снимок приложения и получить самое последнее состояние. Но как это работает с основным в автономном режиме? Есть ли резервные копии, реплицированные в другое место, и достаточно ли они свежие для использования? Можно ли выполнить перемещение с основным автономным сервером, учитывая, что это может также исключить управление резервными копиями, хостами виртуальных машин, базами данных, DNS и другими компонентами?
Восстановить работу центра обработки данных непросто. Вам нужны все данные, которые уже скопированы с сайта, прежде чем это произойдет, и при этом вы сможете контролировать ситуацию.
Один из вариантов - дублировать и изолировать всю инфраструктуру в каждом центре обработки данных: реплицированную базу данных, серверы приложений, локальный балансировщик нагрузки, отдельные кластеры узлов виртуальных машин и все остальное. Переключение осуществляется путем изменения DNS или IP-маршрутизации. Преимущество: изолированные домены отказа, так как они мало зависят друг от друга. Недостаток: отдельные системы, требующие обслуживания, переключение может оказаться весьма значительным процессом, на выполнение которого потребуется время.
Облако принципиально не меняет планирование непрерывности бизнеса. Только то, что вы передаете физический центр обработки данных на аутсорсинг. И, возможно, у вас есть дополнительные управляемые услуги на выбор.
Я не стал описывать возможные режимы отказа, не говоря уже о технологиях высокой доступности, которые могут помочь в быстром переключении. Продолжайте планировать, улучшать процессы и тестировать. Всегда помня о потребностях организации в непрерывности бизнеса.