Конфиденциальность, целостность, доступность - этот набор слов знаком каждому, кто крутится около ИБ, независимо от глубины погружения. И если с первыми двумя все понятно, то третье часто отодвигается в сторону функционала ИТ/телеком.
При внедрении практически каждого ИТ-/ИБ-/телеком-решения поднимается вопрос отказоустойчивости. Особенно в случае, если решение обрабатывает продуктивный трафик, либо предоставляет востребованный внутренними/внешними клиентами сервис. Так что же нужно сделать, чтобы ее обеспечить? Статей на этот счет написано немало, так что не буду и я исключением.
Высокая доступность обеспечивается совокупностью следующих факторов:
Наличие резервного оборудования
В случае аппаратного сбоя, потери связи либо выхода из строя компонентов решения наличие ещё одной идентичной платформы будет критичным для самой возможности обеспечения кластеризации. Актуально как для компонентов внутри платформы (диски, интерфейсы), активного и пассивного сетевого оборудования, так и для отдельных аппаратных реализаций в резерве.
Наличие резервных источников энергообеспечения
Админ возомнил себя всесильным, но энергетик быстро его переубедил. Без источника энергии активное оборудование работать не будет, сбой в штатном электропитании тоже нужно предусмотреть и защититься от него. Автоматические предохранители, аккумуляторы и дизель-генераторы, резервные блоки питания, подключенные к разным вводам, подключение ЦОД к разным электросетям - все это поможет избежать блекаута.
Отказоустойчивая архитектура
Сервис, предоставляемый техническим решением, проектируется с учетом определенных требований. В списке этих требований должна присутствовать высокая доступность и отсутствие/минимизация перерыва в предоставлении сервиса при сбое либо выходе из строя его компонентов.
Конфигурация среды виртуализации либо аппаратной платформы
Функционал многих сред виртуализации позволяет автоматически, незаметно для конечного пользователя, перебрасывать продуктивную виртуальную машину на резервный гипервизор при сбое, остановке либо выходе из строя основного. Аналогичный функционал по переносу продуктивной нагрузки на резервную ноду зачастую реализован в невиртуализируемых аппаратных платформах. Это нужно учитывать.
Конфигурация сети
Для нормальной отказоустойчивой работы кластера и прозрачного переключения нагрузки при сбое необходимо правильно сконфигурировать сетевое оборудование, к которому подключается кластер. Это как технологии first hop redundancy, spanning tree (либо non-spanning tree резервируемые реализации) и path redundancy, так и банальная коммутация разных нод в разные коммутаторы.
Конфигурация ПО
ПО должно поддерживать технологии отказоустойчивости более низких уровней модели OSI либо управлять ими, и быть соответствующим образом сконфигурировано. А если нет - хотя бы не конфликтовать с более низкоуровневой реализацией горячего резервирования.
Наличие лицензий
Даже если все вышеописанные условия соблюдены - ещё не поздно сделать кластер неполноценным. Для этого достаточно не учесть необходимость лицензии на реализацию отказоустойчивого решения при внедрении коммерческого продукта.
Надеюсь, этот краткий и обобщенный checklist поможет кому-то при реализации правильно построенного сервиса.
Комментариев нет:
Отправить комментарий