«Эталонные архитектуры максимальной доступности Oracle (Oracle Maximum Availability Architecture) Основа подхода DBaaS (база данных как сервис) ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ORACLE | СЕНТЯБРЬ...»
Availability Architecture (MAA)
Эталонные архитектуры максимальной доступности
Oracle (Oracle Maximum Availability Architecture)
Основа подхода DBaaS (база данных как сервис)
ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ORACLE | СЕНТЯБРЬ 2015
Введение 1
Эталонные архитектуры высокой доступности - обзор 2
Bronze: одиночный экземпляр 4 Высокая доступность и защита данных в Oracle Database 4 Консолидация баз данных на уровне Bronze 5 Управление жизненным циклом и предоставление базы данных как сервис (DBaaS) 5 Комплексы Oracle Engineered Systems 5 Заключение по уровню Bronze: защита данных, RTO и RPO 6 Silver: высокая доступность с автоматическим переключением на резерв 7 Oracle Real Application Clusters (Oracle RAC) 8 Oracle RAC One Node 8 Заключение по уровню Silver: защита данных, RTO и RPO 9 Gold: комплексные возможности высокой доступности и аварийного восстановления 9 Oracle Active Data Guard - защита данных в реальном времени и высокая доступность 10 Oracle GoldenGate 11 Oracle Site Guard 12 Заключение по уровню Gold: защита данных, RTO и RPO 13 Platinum: отсутствие простоев для приложений, готовых к уровню сервиса Platinum 14 Технология Application Continuity 14 Oracle Active Data Guard Far Sync 15
Техническое обслуживание без простоев с помощью GoldenGate и репликация «активный-активный» 15 Функция Edition Based Redefinition 16 Решение Oracle Global Data Services 16 Заключение по уровню Platinum: защита данных, RTO и RPO 17 Заключение 17ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Введение В современном мире компании испытывают сильное давление делать больше с меньшими затратами, снижать риски и повышать гибкость. Активная консолидация ИТ-технологий и развертывание DBaaS (база данных как сервис) в публичных и частных облаках - стратегия, к которой обращаются многие компании для достижения этой цели. Оба этих направления развития существенно влияют на разработку и внедрение архитектур для высокой доступности и защиты данных.В результате консолидации баз данных серьезно усугубляются проблемы простоев и потери данных. Последствия выхода из строя одной автономной среды, используемой одним разработчиком или небольшой рабочей группой, часто незначительны. Такой выход из строя консолидированной среды, поддерживающей весь коллектив разработчиков организации, или сбой множества приложений, используемых многими отделами, может нарушить работу компании. В этом примере уровни обслуживания, обеспечивающие высокую доступность и защиту данных консолидированной среды, гораздо важнее, чем прежние уровни обслуживания для автономных сред.
Для консолидации данных и подхода DBaaS также требуется стандартизация ИТ-услуг и процессов. Стандартизация - важное условие снижения расходов и сложности эксплуатации. При правильной стандартизации также может значительно повыситься гибкость организации, позволяя службам ИТ быстро реагировать на меняющиеся потребности бизнеса.
В архитектуре максимальной доступности Oracle (Oracle Maximum Availability Architecture) определены четыре эталонные архитектуры высокой доступности, которые обеспечивают нужный уровень стандартизации и одновременно решают весь комплекс проблем доступности и защиты данных в организациях любого размера и направления бизнеса.
В этой статье подробно рассмотрена каждая эталонная архитектура и соответствующие уровни обслуживания, которых можно достичь. Статья предназначена в основном для технических специалистов: архитекторов, директоров по ИТ и администраторов баз данных, ответственных за проектирование и внедрение подхода DBaaS. Рекомендованные лучшие практики одинаково подходят для любой платформы, которую поддерживает СУБД Oracle Database, если специально не указано, что данная оптимизация предназначена только для Oracle Engineered Systems.
1 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Эталонные архитектуры высокой доступности - обзор Лучшие практики Oracle MAA определяют четыре эталонные архитектуры высокой доступности, позволяющие полностью обеспечить доступность системы и защиту данных для организаций любых размеров и направлений бизнеса. Эти архитектуры или уровни высокой доступности обозначены как PLATINUM (ПЛАТИНОВЫЙ), GOLD (ЗОЛОТОЙ), SILVER (СЕРЕБРЯННЫЙ) И BRONZE (БРОНЗОВЫЙ).Они обеспечивают уровни обслуживания, описанные на рис. 1.
– – –
Рис. 1. Уровни обслуживания для высокой доступности и защиты данных На каждом уровне используется собственная эталонная архитектура MAA для развертывания оптимального набора средств высокой доступности Oracle, которые надежно обеспечат заданный уровень обслуживания с минимальными расходами и сложностью. Они решают проблемы любых внеплановых отключений, включая повреждение данных, отказ одного из компонентов, выход из строя системы или отключение центра обработки данных, а также плановых отключений для техобслуживания, миграции или других целей. Общее описание каждой архитектуры представлено на рис. 2.
Рис. 2. Эталонные архитектуры высокой доступности и защиты данных
Уровню Bronze соответствуют базы данных, где простой перезапуск или восстановление из резервной копии считается «достаточно высокой доступностью». Уровень Bronze основан на одиночном экземпляре СУБД Oracle Database и использует лучшие практики архитектуры MAA, которые включают множество средств защиты данных и высокой доступности, включенных в лицензию Oracle Enterprise Edition.
Резервные копии, оптимизированные Oracle с помощью Oracle Recovery Manager (RMAN), обеспечивают
2 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
защиту данных и используются для восстановления в случае, когда перезапуск базы данных невозможен.Уровень Silver обеспечивает дополнительную степень высокой доступности для баз данных, требующих минимального или нулевого простоя при выходе из строя экземпляра БД или сервера, а также для большинства видов планового простоя на обслуживание. Уровень Silver дополнен технологией кластеризации - Oracle RAC или RAC One Node. RMAN предоставляет резервные копии баз данных для защиты данных и восстановления доступности, если отключение делает перезапуск кластера невозможным.
Уровень Gold значительно повышает уровень обслуживания для критически важных бизнес-приложений, где отказ ни одного из компонентов не приводит к выходу из строя всей системы. Уровень Gold дополнен технологиями репликации баз данных: Active Data Guard и Oracle GoldenGate. Эти технологии синхронизируют одну или более реплик производственной базы данных для обеспечения защиты данных в реальном времени и высокой доступности. Репликация баз данных обеспечивает значительно более высокий уровень доступности и защиты данных, чем технологии репликации на уровне системы хранения. Она также снижает расходы и повышает выгоду от инвестиций благодаря постоянному активному использованию всех реплик.
Уровень Platinum предоставляет несколько новых возможностей Oracle Database 12c, а также ранее доступные продукты, расширенные в новой версии. В него включены технология Application Continuity для надежного повтора выполняемых транзакций, Active Data Guard Far Sync для полной защиты от потери данных при любом удалении реплики от основной БД, новые расширения GoldenGate для обновления и миграций без простоев и Global Data Services для автоматического управления и балансировкой нагрузки для репликаций БД. Хотя внедрение каждой из технологий требует значительных усилий, это обеспечивает значительные преимущества для критически важных приложений, где простои и потеря данных недопустимы.
В следующей таблице суммируются атрибуты высокой доступности (HA) и защиты данных, встроенные в каждую эталонную архитектуру.
ВЫСОКАЯ ДОСТУПНОСТЬ И ЗАЩИТА ДАННЫХ
– – –
Эталонные архитектуры MAA по своей сути предназначены для решения противоречивых задач.
С одной стороны, не у каждого приложения одни и те же требования высокой доступности и защиты данных. С другой стороны, стандартная архитектура - это эксплуатационное требование и обязательное условие для бизнеса, если требуется снизить сложность и расходы.
Эталонная архитектура MAA учитывает обе реальности и предоставляет инфраструктуру, которая оптимизирована для Oracle Database и позволяет задать нужный уровень HA для разных требований к уровню сервиса. Благодаря этому можно легко перенести базу данных на следующий уровень в случае изменения бизнес-требований или при
3 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
переходе с одной аппаратной платформы на другую.В следующих разделах каждая эталонная архитектура описывается более подробно.
Bronze: одиночный экземпляр Уровень Bronze предоставляет базовый сервис БД с самыми низкими расходами. Расходы и сложность внедрения снижаются за счет более низкого уровня доступности и защиты данных. На рис. 3 представлен общий вид уровня Bronze.
Уровень Bronze использует один экземпляр БД Oracle Database; никакая технология кластеризации не используется в случае отказа сервера для автоматического переключения на резерв, на котором есть работающий экземпляр Oracle Database. Если выходит из строя сервер или база данных, целевое время восстановления (RTO) зависит от того, насколько быстро можно предоставить другое оборудование на замену или выполнить восстановление из резервной копии. В худшем сценарии полного отключения вычислительной площадки потребуется дополнительное время для выполнения этих задач на резервном узле, и в некоторых случаях на это могут потребоваться дни.
Уровень Bronze: одиночный экземпляр RTO от минут до дней, RPO со времени последнего резервного копирования Рис. 3. Эталонная архитектура высокой доступности Bronze Oracle Recovery Manager (RMAN) используется для регулярного резервного копирования СУБД Oracle Database.
Возможная потеря данных, называемая целевой точкой восстановления (RPO), - это все данные, сформированные после создания последней резервной копии. Копии резервных копий баз данных также хранятся в удаленном ЦОД или облаке в целях архивации и для аварийного восстановления в случае аварии в основном ЦОД.
Уровень Bronze состоит из основных компонентов, описанных в следующих разделах.
Высокая доступность и защита данных в Oracle Database На уровне Bronze используются следующие средства высокой доступности и защиты данных, включенные в Oracle Database Enterprise Edition без дополнительной платы.
Oracle Restart автоматически перезапускает базу данных, Listener и другие компоненты »
Oracle после аппаратного или программного выхода из строя или каждый раз, когда перезапускается компьютер с базой данных.
Средства Oracle для защиты от повреждений проверяют наличие физических »
повреждений и логических внутриблоковых повреждений. Повреждения данных в оперативной памяти обнаруживаются и не попадают на диск. Во многих случаях они могут быть устранены автоматически. Дополнительные сведения см. в разделе Preventing, Detecting, and Repairing Block Corruption for the Oracle Database (Предотвращение, обнаружение и устранение поврежденных блоков для Oracle Database).
Automatic Storage Management (ASM) - интегрированная с Oracle файловая система »
4 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
и менеджер томов с автоматическим зеркалированием для защиты от выхода из строя диска.Oracle Flashback Technologies - группа функций, обеспечивающих быстрое исправление »
ошибок различного вида, необходимы для восстановления определенной транзакции, таблицы или всей базы данных.
Oracle Recovery Manager (RMAN) обеспечивает экономичное и надежное резервное »
копирование и восстановление, оптимизированное для Oracle Database.
Online Maintenance - функция, которая включает переопределение и реорганизацию »
данных без остановки для технического обслуживания баз данных, переноса файлов и патчирования.
Консолидация баз данных на уровне Bronze Базы данных, развернутые на уровне Bronze, включают базы данных для разработки и тестирования, а также для небольших рабочих групп и приложений отдельных подразделений, которые часто являются первыми кандидатами на консолидацию баз данных и предоставление базы данных как сервис (DBaaS).
Oracle Multitenant - методология MAA для консолидации и виртуализации баз данных, начиная с версии Oracle Database 12c. Другие опции консолидации включают следующее.
Виртуализация операционной системы - несколько виртуальных машин на одной физической хост-машине »
Консолидация схем - разные схемы приложений в одной базе данных »
Консолидация платформ - несколько отдельных баз данных на одной физической машине или в одном »
кластере Oracle RAC Компромиссы между Oracle Multitenant и другими методами консолидации обсуждаются в технической статье по Архитектуре Максимальной Доступности Oracle (Oracle Maximum Availability Architecture) «High Availability Best Practices for Database Consolidation» (Лучшие практики высокой доступности для консолидации баз данных).
Управление жизненным циклом и предоставление базы данных как сервис (DBaaS) Oracle Enterprise Manager Cloud Control - обеспечивает развертывание ИТ-ресурсов пользователями самостоятельно согласно модели пулов ресурсов для разных мультиарендных архитектур. Эти возможности необходимы для внедрения подхода DBaaS (база данных как сервис) - парадигмы, в которой конечные пользователи (АБД, разработчики приложений, инженеры по качеству обслуживания, руководители проектов и т. д.) могут запрашивать сервис баз данных, использовать их в течение жизненного цикла проекта, а затем освободить их и вернуть в пул ресурсов. С помощью Cloud Control Database as a Service (DBaaS) обеспечивается следующее.
Общая консолидированная платформа для предоставления сервиса базы данных »
Модель самообслуживания для развертывания этих ресурсов »
Гибкое увеличение и уменьшение ресурсов базы данных »
Взимание платы только за использованные ресурсы БД »
Комплексы Oracle Engineered Systems Комплексы Oracle Engineered Systems снижают расходы в течение всего жизненного цикла за счет стандартизации на предынтегрированной и оптимизированной платформе для СУБД Oracle Database и приложений. Комплексы Oracle Engineered Systems включают следующее.
Oracle Virtual Compute Appliance - кардинально упрощает для заказчиков установку и развертывание »
виртуальных инфраструктур для любого приложения Linux, Oracle Solaris или Microsoft Windows, а также управление ими.
Oracle Database Appliance - недорогой комплексный пакет программного обеспечения, систем хранения »
данных, серверных и сетевых средств, который снижает сложность и экономит время и деньги, упрощая
5 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
развертывание, техническое обслуживание и поддержку баз данных и приложений. Oracle Database Appliance поддерживает как физические, так и виртуальные развертывания.Программно-аппаратный комплекс Oracle Exadata Database Machine - самая высокопроизводительная, »
масштабируемая и доступная платформа для работы Oracle Database. Oracle Exadata Database Machine работает с приложениями любых типов, включая оперативную обработку транзакций (OLTP), хранилища данных (DW) и консолидацию приложений смешанного типа нагрузки, что создает идеальную основу для консолидации баз данных.
Oracle SuperCluster - специализированные системы, идеальные для консолидации баз данных и »
приложений, развертываний в частном облаке и использования программного обеспечения Oracle на единой универсальной платформе. Oracle SuperCluster использует самые быстрые процессоры в мире на основе архитектуры SPARC и системы хранения Exadata.
Oracle ZFS Storage Appliance обеспечивает немедленные преимущества экономии дискового »
пространства, управления и экономии средств для заказчиков, используюя сетевую систему хранения (NAS). Oracle ZFS включает многофункциональный пакет ПО для управления, мониторинга, устранения неисправностей, моментальных копий, клонирования, тиражирования и дополнительные сервисы хранения данных, естественно дополняя все системы Oracle Engineered Systems.
Заключение по уровню Bronze: защита данных, RTO и RPO В таблице ниже суммируются все возможности защиты данных уровня Bronze. В первом столбце таблицы 2 указано, когда выполняются проверки на наличие физического и логического повреждения данных.
Ручные проверки инициируются администратором или через регулярные интервалы времени »
плановым заданием, выполняющим периодические проверки.
Проверки на лету постоянно выполняются фоновыми процессами, когда база данных открыта.
Фоновые проверки выполняются через заданные регулярные интервалы времени, но только в »
периоды, когда ресурсы не используются.
Каждая проверка уникальна для Oracle Database и использует специальные знания структуры блоков данных Oracle и журналов базы данных.
ЗАЩИТА ДАННЫХ BRONZE
– – –
Обратите внимание, что проверка HARD и функция Automatic Hard Disk Scrub and Repair уникальны для системы хранения Exadata. Благодаря проверке HARD СУБД Oracle Database не записывает физически поврежденные блоки на диск. Automatic Hard Disk Scrub and Repair периодически определяет и восстанавливает жесткие диски с поврежденными или изношенными секторами (кластер системы хранения), а также обнаруживает и устраняет другие физические и логические дефекты, когда есть свободные ресурсы.
Exadata посылает запрос в ASM на восстановление поврежденных секторов путем считывания данных из другой зеркальной копии. По умолчанию очистка диска (scrub) выполняется каждые две недели.
6 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
В следующей таблице показаны RTO и RPO уровня Bronze для различных плановых и внеплановых простоев.ВРЕМЯ ВОССТАНОВЛЕНИЯ (RTO) И ВОЗМОЖНАЯ ПОТЕРЯ ДАННЫХ (RPO) НА УРОВНЕ BRONZE
– – –
Silver: высокая доступность с автоматическим переключением на резерв Уровень Silver основан на уровне Bronze, но включает технологию кластеризации для повышенной доступности во время внеплановых простоев и планового обслуживания (рис. 4). Уровень Silver использует технологию кластеризации Oracle RAC или Oracle RAC One Node для обеспечения высокой доступности в ЦОД. Это достигается путем автоматического переключения на резерв в случае отключения одного из экземпляров базы данных или в случае полного выхода из строя сервера, на котором работает экземпляр базы данных. Oracle RAC дает еще одно существенное преимущество - устраняет различные типы плановых простоев благодаря возможности техническому обслуживания узлов кластера Oracle RAC поочередно Уровень Silver: высокая доступность с быстрым переключением на резерв RTO за секунды в случае выхода сервера из строя, RPO со времени последнего резервного копирования Рис. 4. Эталонная архитектура высокой доступности Silver
7 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Уровень Silver включает компоненты высокой доступности, описанные в следующих разделах.Oracle Real Application Clusters (Oracle RAC) Oracle RAC повышает доступность приложения внутри ЦОД в случае отказа экземпляра базы данных или сервера, на котором работает экземпляр. Переключение на резервный сервер с Oracle RAC происходит мгновенно. Время восстановления сервиса на оставшихся экземплярах и повторного подключения пользователей отказавшего узла практически незаметно.
Также исключаются простои для задач планового обслуживания, которые могут выполняться поочередно для всех узлов Oracle RAC. Пользователи завершают свою работу и закрывают свои сессии на узле, где будет проводиться обслуживание. При повторном подключении они получают доступ к экземпляру базы данных, уже работающему на другом узле.
Краткий обзор того, как работает кластер Oracle RAC, помогает понять его преимущества. Существует два компонента: экземпляры Oracle Database и сама СУБД Oracle Database.
Экземпляр базы данных определяется как набор серверных процессов и структур памяти, которые работают »
на одном узле (или сервере) и делают конкретную базу данных доступной для клиентов.
База данных - определенный набор файлов с общим доступом (файлы данных, индексные файлы, »
управляющие файлы и файл инициализации), которые хранятся на диске и вместе могут открываться и использоваться для чтения и записи данных.
Oracle RAC использует архитектуру «активный-активный», в которой может быть несколько экземпляров баз »
данных, работающих на разных узлах, для одновременного чтения и записи данных в одной и той же базе данных.
Архитектура «активный-активный» кластера Oracle RAC обеспечивает следующие преимущества.
Повышение уровня высокой доступности. Отказ сервера или экземпляра базы данных не затрагивает »
подключения к остальным экземплярам, а подключения к отказавшему экземпляру быстро переносятся на другие экземпляры, которые уже работают и открыты на других серверах кластера.
Масштабируемость. Кластер Oracle RAC идеален для приложений и консолидированных сред, где »
требуется масштабируемость и возможность динамически добавлять вычислительную мощности и менять их приоритеты на более чем одном сервере. Одна база данных может иметь экземпляры, работающие на одном или нескольких узлах кластера. Точно так же один и тот же сервис базы данных может быть доступен на одном или нескольких экземплярах базы данных. Дополнительные узлы, экземпляры баз данных и сервисы баз данных могут переопределяться без остановки кластера. Возможность легко распределять рабочие нагрузки по всему кластеру делает Oracle RAC идеальным дополнением к Oracle Multitenant.
Надежная производительность. Oracle Quality of Service (QoS) может использоваться для назначения »
ресурсов высокоприоритетным сервисам баз данных и обеспечения стабильно высокой производительности в консолидированных средах баз данных. Вычислительные мощности могут динамически перераспределяться для быстрой адаптации к меняющимся требованиям.
Высокая доступность во время планового обслуживания. Высокая доступность обеспечивается благодаря »
внесению изменений на узлах Oracle RAC поочередно. Это включает обслуживание оборудования, ОС или сети, когда сервер должен быть переведен в автономный режим, внесение патчей в программный стек Oracle Grid Infrastructure или базу данных, а также обслуживание, когда необходимо перенести экземпляр базы данных на другой сервер для повышения вычислительной мощности или распределения нагрузки.
Oracle RAC - лучшая практика MAA для обеспечения высокой доступности серверов.
Oracle RAC One Node Oracle RAC One Node обеспечивает альтернативу кластеру Oracle RAC на уровне Silver, когда высокая доступность сервера необходима, а масштабируемость и мгновенное переключение на резерв не требуются. Лицензия Oracle RAC One Node стоит вдвое дешевле, чем Oracle RAC, и является менее дорогой альтернативой, если в случае отказов серверов достаточно RTO в минутах.
8 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Oracle RAC One Node - технология переключения на резерв «активный-пассивный». Она основана на той же инфраструктуре, что и Oracle RAC, но в случае Oracle RAC One Node во время штатной работы в каждый момент времени открыт только один экземпляр базы данных.В случае отказа сервера, на котором размещена открытая база данных, Oracle RAC One Node автоматически запускает новый экземпляр базы данных на втором узле для быстрого возобновления сервиса.
Oracle RAC One Node имеет ряд преимуществ над другими технологиями кластеризации «активный-пассивный».
В конфигурации Oracle RAC One Node сервисы Oracle Database HA Services, инфраструктура Grid Infrastructure и прослушивающие процессы базы данных всегда работают на втором узле. Во время аварийного переключения на резерв требуется запуск только экземпляра базы данных и сервисов базы данных, что ускоряет возобновление обслуживания и дает возможность перезапустить службы за минуты.
Для планового обслуживания Oracle RAC One Node обеспечивает те же преимущества, что и Oracle RAC. В кластере RAC One Node в период планового технического обслуживания два активных экземпляра базы данных могут обеспечить плавную миграцию пользователей с одного узла на другой с нулевым временем простоя. Обслуживание узлов осуществляется в скользящем режиме, и в это время сервисы баз данных остаются доступными для пользователей.
Заключение по уровню Silver: защита данных, RTO и RPO Уровень защиты данных такой же, как на уровне Bronze. Улучшения на уровне Silver по сравнению с уровнем Bronze связаны с RTO в случае отказа сервера и с некоторыми, часто выполняемыми видами планового ТО. Области улучшения по сравнению с уровнем Bronze показаны жирным шрифтом в следующей таблице.
ВРЕМЯ ВОССТАНОВЛЕНИЕ (RTO) И ВОЗМОЖНЫЕ ПОТЕРИ ДАННЫХ (RPO) НА УРОВНЕ SILVER
– – –
Gold: комплексные возможности высокой доступности и защиты от сбоев Уровень Gold основан на уровне Silver, но использует технологию репликации баз данных для устранения единой точки отказа, который может вызвать выход из строя всей системы, а также для значительного повышения уровня защиты и доступности данных для всех типов внеплановых сбоев, включая повреждения данных, отказы баз данных и отказы ЦОД. Наличие тиражированной копии также значительно сокращает простои в периоды планового обслуживания. Общий вид уровня Gold показан на рис. 5.
9 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
RTO снижается до секунд или минут, а RPO - до нуля или почти до нуля в зависимости от конфигурации.Уровень Gold: комплексные возможности высокой доступности и защиты от сбоев RTO от секунд до минут, RPO до нуля или почти до нуля Рис. 5. Эталонная архитектура высокой доступности Gold Обратите внимание, что уровень Gold использует Oracle RAC как стандарт для высокой доступности серверов вместо менее функционального Oracle RAC One Node, доступного на уровне Silver.
Уровень Gold добавляет компоненты для более высоких уровней обслуживания, описанных в следующих разделах.
Oracle Active Data Guard - защита данных в реальном времени и высокая доступность Oracle Active Data Guard поддерживает одну или несколько синхронизированных физических реплик (резервных баз данных) на удаленном узле для устранения единой точки отказа, которой мог бы привести к выходу из строя основной базы данных. Основываясь на лучших практиках MAA, предлагается использовать одну и ту же конфигурацию для основной и резервной баз данных (ЦП, память, ввод-вывод и т. д.), чтобы резервная база данных после аварийного переключения на нее могла обеспечить ту же производительность, что и исходная основная.
Active Data Guard добавляет следующие возможности на уровне Gold.
Выбор защиты для нулевой или практически нулевой потери данных. Active Data Guard выполняет »
репликацию изменений из основной базы в резервную в реальном времени. Изменения передаются непосредственно из журнального буфера основной базы данных, чтобы свести к минимуму задержки репликации и влияние на основную БД, а также для полной изоляции процесса репликации от повреждений, которые могут возникнуть в стеке ввода-вывода производственной базы данных.
Администраторы могут выбрать синхронную передачу в режиме защиты Maximum Availability (Максимальная »
доступность) для гарантии нулевой потери данных. Или они могут выбрать асинхронную передачу в режиме Maximum Performance (Максимальная производительность) с почти нулевой потерей данных. Режим Maximum Performance может ограничить возможность потери данных интервалом менее одной секунды, если пропускная способность сети достаточна для размера реплицируемых данных.
Data Guard и Active Data Guard - это единственные технологии репликации Oracle, обеспечивающие защиту »
с нулевой потерей данных.
Резервная база данных Oracle Active Data Guard может быстро принять на себя производственную нагрузку »
и восстановить сервис, если из-за отказа базы данных или отключения вычислительной площадки основная база данных становится недоступной. СУБД Oracle Database всегда работает, ее не нужно перезапускать, и передача роли основной БД может завершиться менее чем за 60 секунд даже в сильно загруженных системах.
10 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Уровень Gold использует функцию Data Guard Fast-Start Failover для автоматического аварийного переключения »базы данных на резерв. Это ускоряет восстановление, устраняя задержку на уведомление администратора, чтобы он мог среагировать на сбой. Fast Start Failover использует ролевые сервисы базы данных и технологию уведомления клиентов Oracle, чтобы приложения могли быстро отключиться от отказавшей основной БД и автоматически подключиться к новой основной. Передача роли БД может производиться вручную через интерфейс командной строки или Oracle Enterprise Manager.
Прозрачная репликация. Data Guard и Active Data Guard выполняют полную, одностороннюю физическую »
репликацию СУБД Oracle Database со следующими характеристиками: высокая производительность, простота управления, поддержка всех типов данных, приложений и видов нагрузок, таких как DML, DDL, OLTP, пакетная обработка и хранилище данных, а также консолидированные базы данных. Data Guard и Active Data Guard тесно интегрируются с технологиями Oracle RAC, ASM, RMAN и Oracle Flashback.
Перенос нагрузки с промышленной БД для большей окупаемости инвестиций. Резервные базы данных Oracle »
Active Data Guard могут быть открыты только для чтения, когда выполняется репликация. Обновленная, активная резервная БД идеальна для переноса на нее тяжелых SQL-запросов и отчетности с основной БД.
Это повышает окупаемость резервных систем и производительность основной БД благодаря использованию вычислительных мощностей, которые иначе бы простаивали. Проводится также постоянная проверка приложений, чтобы резервные базы данных были готовы принять нагрузку в случае отключения основной базы данных.
Освобождение основной БД от задач резервного копирования. Основная и резервная системы являются »
точными физическими копиями друг друга, что позволяет перенести задачи резервного копирования с основной БД на резервную. Резервная копия, созданная на резервной БД, может использоваться для восстановления основной или резервной БД. Это предоставляет администраторам гибкость процесса восстановления, а производственным системам не нужно нести бремя резервного копирования.
Снижение простоев для планового обслуживания. Резервные БД могут использоваться для обновления на »
новый патчсет (например, патч для перехода с версии 11.2.0.2 на 11.2.0.4) или для перехода на новую версию Oracle (например, с 11.2 на 12.1) поочередно: сначала обновляется резервная база данных, после чего она становится производственной уже с новой версией. Общее время простоя снижается до времени передачи роли основной базы данных резервной базе данных и времени переключения пользователей на новую основную базу данных после окончания обновления.
Резервная база данных Oracle Active Data Guard выполняет постоянную проверку данных, чтобы никакие »
повреждения не могли быть скопированы из исходной базы данных. Oracle Active Data Guard обнаруживает физические и логические повреждения блоков, которые могут возникнуть в основной или резервной базе данных. Это также уникальное средство обнаружения повреждений блоков при записи (потерянных или потерявшихся операций записи, признанных успешными подсистемой ввода-вывода). Дополнительные сведения доступны в документе My Oracle Support Note 1302539.1 - Best Practices for Corruption Detection, Prevention, and Automatic Repair (Лучшие практики обнаружения, предотвращения и автоматического устранения повреждений блоков БД).
Автоматическое восстановление блоков. Oracle Active Data Guard автоматически устраняет повреждения на »
уровне блоков, вызванные случайными ошибками ввода-вывода, которые могут возникнуть как на основной, так и резервной БД. Это делается путем извлечения хорошей копии блока из противоположной БД. Никакие изменения в приложениях не требуются, и исправление происходит незаметно для пользователей.
Вышеуказанное также объясняет, почему уровень Gold использует технологию репликации для поддержания синхронизированной копии, а не продукты удаленного зеркалирования системы хранения (SRDF, Hitachi TrueCopy и т. д.). Дополнительные сведения об этих различиях см. в разделе Oracle Active Data Guard vs. Storage Remote Mirroring (Сравнение Oracle Active Data Guard и удаленного зеркалирования системы хранения).
Oracle GoldenGate Программное обеспечение Oracle GoldenGate обеспечивает логическую репликацию для поддержания синхронизированной копии (целевая база данных) основной базы данных (исходная база данных). Oracle GoldenGate считывает изменения с диска исходной базы данных, переводит данные в файловый формат, независимый от платформы, передает файл в целевую базу данных и затем превращает данные в операторы SQL (обновления, вставки и удаления), нативные для целевой базы данных. Целевая БД содержит те же данные, но это уже не исходная, а другая БД (например, резервные копии не взаимозаменяемы). Логическая репликация - это более
11 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
сложный процесс, чем физическая репликация, но она дает больше гибкости для различных сценариев репликации и для разнородных платформ.С точки зрения распределения данных логическая репликация предназначена для экономичной »
репликации подмножеств исходной БД с целью распространения данных на другие целевые БД. Она также может использоваться для консолидации данных из нескольких исходных БД в одну целевую БД (например, Operational Data Store).
С точки зрения высокой доступности логическая репликация может использоваться для поддержания »
полной реплики исходной БД для высокой доступности или защиты от сбоев, переключение на резервную БД может выполнено немедленно.
Логическая репликация Oracle GoldenGate позволяет гибко проводить техническое обслуживание и »
миграцию поочередно, когда с репликацией Data Guard это невозможно. Например, Oracle GoldenGate обеспечивает репликацию из исходной БД на платформе, использующей порядок байтов big-endian в целевую БД на платформе с little-endian (cross-endian репликация). Это позволяет получить дополнительное преимущество от миграции с платформы на платформу: можно изменить направление репликации на обратное для быстрого возврата к предыдущей версии после перехода.
Логическая репликация Oracle GoldenGate - более сложный процесс с большим числом предварительных требований, чем у Data Guard. Но это компенсируется уникальными способностями Oracle GoldenGate обеспечить современные виды репликации. Документ MAA Best Practices: Oracle Active Data Guard and Oracle GoldenGate (Лучшие практики MAA: Oracle Active Data Guard и Oracle GoldenGate) содержит дополнительные сведения для выбора оптимальной технологии репликации или использования обеих технологий как дополняющих друг друга.
Oracle Site Guard Oracle Site Guard дает возможность администраторам координировать как плановые, так и внеплановые переключения (в случае непредвиденного отключения основного ресурса) целиком окружения Oracle (несколько баз данных и приложений) между производственным сайтом и удаленным. Oracle Site Guard входит в пакет Oracle Enterprise Manager Life-Cycle Management Pack.
Oracle Site Guard дает следующие преимущества.
Снижения числа ошибок благодаря готовой реакции на выход из строя узла. Oracle Site Guard »
снижает вероятность человеческих ошибок в случае аварий. Стратегии восстановления разрабатываются, тестируются и проходят проверку на отказ в рамках приложения. Если администратор инициирует операцию Site Guard для восстановления при катастрофических сбоях, участие человека не требуется.
Координация множества приложений, баз данных и различных технологий репликации. Oracle Site »
Guard автоматически обрабатывает зависимости между разными компонентами при запуске или остановке сайта.
Site Guard интегрируется с Oracle Active Data Guard для координации одновременных аварийных переключений нескольких баз данных на резерв. Site Guard также обеспечивает простой механизм интеграции любого продукта для удаленного зеркалирования системы хранения. Это ПО интегрируется с устройствами хранения для планового или аварийного переключения ресурсов на резерв. Для этого вызываются определенные сценарии передачи ролей для систем хранения.
Ускорение восстановления. Автоматизация Oracle Site Guard сводит к минимуму ручную »
координацию операций восстановления. Это ускоряет восстановление даже по сравнению со случаем, когда все ручные операции выполняются успешно. Site Guard экономит время и благодаря тому, что не приходится устранять последствия человеческих ошибок, часто возникающих при выполнении сложных процедур вручную.
12 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Заключение по уровню Gold: защита данных, RTO и RPO В следующей таблице показаны возможности защиты данных, RTO и RPO уровня Gold.Области улучшений выделены жирным шрифтом.
ЗАЩИТА ДАННЫХ УРОВНЯ GOLD
– – –
13 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Platinum: отсутствие простоев для приложений, готовых к уровню сервиса Platinum Уровень Platinum основан на уровне Gold и обеспечивает высокий уровень доступности и защиты данных для приложений, где отключения или потери данных абсолютно недопустимы. Уровень Platinum предоставляет несколько новых возможностей Oracle Database 12c, а также ранее доступные продукты, расширенные в новой версии.Platinum делает отключения незаметными для приложения и пользователей, и даже транзакции, выполняемые в момент отключения, повторяются на лету после восстановления. Время простоя для технического обслуживания, миграций и обновления приложений равно нулю. Гарантируется нулевая потеря данных в случае выхода из строя основной БД по любой причине, независимо от расстояния между основным и резервным узлами. Уровень Platinum также автоматически управляет доступностью сервисов базы данных и балансировкой нагрузки между репликами на нескольких узлах. Общий вид уровня Platinum показан на рис. 6.
Уровень Platinum Отсутствие простоев для приложений, готовых к уровню сервиса Platinum
– – –
Рис. 6. Эталонная архитектура высокой доступности Platinum Для полного исключения простоев на уровне Platinum многим приложениям потребуются незначительные изменения. Вот почему мы говорим, что уровень Platinum обеспечивает нулевое время простоя только приложениям, готовым к уровню Platinum. Обратите внимание, что для нулевой потери данных никакие изменения в приложениях не требуются.
На уровне Platinum используются средства обеспечения высокой доступности, описанные в следующих разделах.
Технология Application Continuity Технология Application Continuity защищает приложения от прерывания сессий базы данных из-за выхода из строя экземпляра, сервера, системы хранения, сети, любого другого компонента и даже всей базы данных. Технология Application Continuity повторяет транзакции, выполняемые в момент отключения, для приложения это просто небольшая задержка выполнения, незаметная для пользователя.
В случае отказа всего кластера Oracle RAC, когда база данных становится недоступной, технология Application Continuity воспроизводит сеанс, в том числе нужную транзакцию, после аварийного переключения на резервной БД с помощью Oracle Active Data Guard. Для использования технологии Application Continuity с резервной базой данных требуется режим Data Guard Maximum Availability и Data Guard Fast Start Failover.
14 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Oracle Active Data Guard Far Sync Data Guard и Active Data Guard - это единственные технологии репликации для работы с Oracle, которые обеспечивают аварийное переключение с нулевой потерей данных для СУБД Oracle Database. Нулевая потеря данных достигается с помощью синхронной передачи в режиме Data Guard Maximum Availability. Если используется синхронная передача, то время ожидания в сети при передачи данных между основным и резервным узлами влияет на производительность базы данных. Чем больше расстояние между узлами, тем больше время ожидания и его влияние на производительность БД. Поскольку основной и резервный ЦОД часто находятся на большом расстоянии друг от друга, выбор нулевой потери данных непрактичен для многих баз данных.Active Data Guard Far Sync устраняет вышеуказанные ограничения, обеспечивая нулевую потерю данных без ухудшения производительности основной базы данных даже в случае, если основная и резервная базы данных находятся в сотнях и даже тысячах километров друг от друга. Это достигается с помощью «легкого» механизма передачи, простого в развертывании и прозрачного для операций аварийного переключения Oracle Active Data Guard или планового переключения. Если Far Sync используется с опцией Oracle Advanced Compression Option, обеспечивается также сжатие данных для передачи за пределы основного сайта для экономии пропускной способности сети.
Если технология Application Continuity используется вместе с Far Sync в режиме Data Guard Fast-Start-Failover (автоматическим аварийным переключением на резерв), она может сделать отключения незаметными для транзакций, выполнявшихся в этот момент, независимо от расстояния между основным и резервным узлами.
Таким образом, Far Sync обеспечивает два основных дополнительных преимущества уровня Platinum: аварийное переключение на резерв без потери данных для любой базы данных и возможность использовать технологию Application Continuity независимо от расстояния между узлами. Active Data Guard Far Sync - новый режим в Oracle Database 12c. Для использования преимуществ Far Sync никакие изменения в приложениях не требуются.
Техническое обслуживание без простоев с помощью GoldenGate и репликация «активный-активный»
Уровень Platinum использует передовые свойства репликации Oracle GoldenGate для технического обслуживания без простоев и для миграций с помощью двусторонней репликации. Рассмотрим следующий сценарий.
Техническое обслуживание сначала выполняется на целевой БД.
Исходная и целевая БД синхронизируются для разных версий БД, использующих логическую репликацию »
Oracle GoldenGate. Это обеспечивает миграции между платформами с прямым и обратным порядком байтов (cross-endian). Это также обеспечивает сложные обновления приложений, которые изменяют серверные объекты, где механизм репликации должен преобразовать данные из старой версии в новую или наоборот.
Когда новая версия платформы стабилизирована и стабильна, двусторонняя репликация дает возможность »
пользователям постепенно и без простоев перейти на новую платформу по мере завершения сессий в прежней версии и подключения к новой. Двусторонняя репликация Oracle GoldenGate поддерживает синхронизацию старой и новой версий во время миграции. Это также позволяет быстро вернуться к старой версии, если возникнут неожиданные проблемы с новой версией по мере добавления нагрузки.
Двусторонняя репликация «активный-активный» может также использоваться для повышения уровней доступности сервиса, когда требуется постоянное подключение к нескольким копиям одних и тех же данных для чтения и записи.
Двусторонняя репликация непрозрачна для приложения. Требуется обнаружение и разрешение конфликтов, когда изменения одновременно вносятся в одну и ту же запись в нескольких БД. Необходимо также учитывать влияние разных видов сбоев и задержки репликации. Если двусторонняя репликация GoldenGate используется для обновлений приложения, изменяющих серверные объекты БД, для репликации между разными версиями требуется на уровне разработчика знание объектов БД, изменяемых или добавляемых в новой версии. Для каждой новой версии приложения требуется сопоставление версий.
15 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Репликация GoldenGate - это асинхронный процесс, не способный обеспечить нулевую потерю данных. Поэтому на уровне Platinum не используется Oracle GoldenGate для репликации между узлами, если удаленная реплика должна исключить потери данных в случае внепланового отключения основной базы данных или основного сайта.Для удовлетворения требования нулевой потери данных уровень Platinum использует двустороннюю репликацию GoldenGate в сочетании с Oracle Active Data Guard.
Локальная реплика GoldenGate используется для планового технического обслуживания без потери данных, а резерв Oracle Active Data Guard стабильно исключает потери данных при аварийном переключении в случае внепланового отключения во время обслуживания.
Функция Edition Based Redefinition Edition-Based Redefinition (EBR) обеспечивает обновления приложения, которые изменяют серверные объекты БД, в сети без нарушения доступности приложения. Когда установка обновлений завершена, старый и обновленный варианты приложения могут использоваться одновременно. Существующие сессии могут продолжать использовать приложение, каким оно было до обновления, пока пользователи не решат прекратить работу, а новые сессии могут использовать уже новую редакцию. Когда сессий, использующих необновленное приложение, не останется, его можно вывести из эксплуатации.
EBR позволяет обновлять приложения в интерактивном режиме следующим образом.
Изменения программного кода вводятся в новой редакции.
Изменения в данных вводятся безопасным способом путем записи только в новые столбцы или новые »
таблицы, невидимые для старой редакции. В специальном представлении редакций (editioning view) таблица отображается особым образом для каждой редакции, чтобы каждая редакция видела только свои столбцы.
Сross-edition распространяет изменения данных, произведенные в старом приложении, на столбцы »
обновленного приложения, и наоборот.
Так же как и с беспростойным обновлением приложения с Oracle GoldenGate, для внедрения и использования EBR требуется глубокое знание приложения и значительные усилия разработчика. В отличие от Oracle GoldenGate для использования EBR достаточно разовой инвестиции. После этого можно использовать EBR для последующих версий приложения с минимальными усилиями. Уже доказана на практике возможность использования EBR для самых сложных приложений. Например, Oracle E-Business Suite 12.2 использует EBR для патчирования без остановки. Возможность EBR добавлена в СУБД Oracle Database без дополнительной платы.
Решение Oracle Global Data Services Oracle Global Data Services (GDS) - комплексное решение по автоматическому управлению нагрузкой для реплицированных БД, использующих Oracle Active Data Guard или Oracle GoldenGate. GDS обеспечивает более высокий коэффициент использования системы, а также более высокий уровень производительности, масштабируемости и доступности для реплицируемых БД.
GDS обеспечивает следующие возможности для набора реплицируемых БД:
– – –
16 | ЭТАЛОННЫЕ АРХИТЕКТУРЫ ORACLE MAA - ОСНОВА ПОДХОДА DBAAS (БАЗА ДАННЫХ КАК СЕРВИС)
Заключение по уровню Platinum: защита данных, RTO и RPO Уровень Platinum обеспечивает такую же защиту от повреждений, как уровень Gold. Различия между уровнями Platinum и Gold связаны со временем восстановления (RTO) и возможной потерей данных (RPO) для приложений, готовых к работе на уровне Platinum.RTO и RPO для уровня Platinum показаны в следующей таблице.
ВРЕМЯ ВОССТАНОВЛЕНИЯ (RTO) И ВОЗМОЖНАЯ ПОТЕРЯ ДАННЫХ (RPO) НА УРОВНЕ PLATINUM
– – –
Заключение Организациям требуются решения для соответствия всему набору требований по защите и доступности данных.
Лучшие практики Oracle MAA определяют четыре эталонные архитектуры высокой доступности:
BRONZE, SILVER, GOLD и PLATINUM. Каждая эталонная архитектура MAA использует оптимальный набор средств высокой доступности Oracle для надежного обеспечения нужного уровня обслуживания с наименьшими расходами и сложностью. Развертывание программных средств высокой доступности и защиты данных, интегрированных в Oracle, с помощью стандартного набора архитектур высокой доступности, использующих общую инфраструктуру, обеспечивает уникальное решение для поддержки подхода база данных как сервис (DBaaS) в публичных или частных облаках.
2017 www.сайт - «Бесплатная электронная библиотека - различные документы»
Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам , мы в течении 1-2 рабочих дней удалим его.
Доступность
Основные понятия
Информационная система предоставляет своим пользователям определенный набор услуг (сервисов). Говорят, что обеспечен нужный уровень доступности этих сервисов, если следующие показатели находятся в заданных пределах:
- Эффективность услуг . Эффективность услуги определяется в терминах максимального времени обслуживания запроса, количества поддерживаемых пользователей и т.п. Требуется, чтобы эффективность не опускалась ниже заранее установленного порога.
- Время недоступности. Если эффективность информационной услуги не удовлетворяет наложенным ограничениям, услуга считается недоступной. Требуется, чтобы максимальная продолжительность периода недоступности и суммарное время недоступности за некоторой период (месяц, год) не превышали заранее заданных пределов.
В сущности, требуется, чтобы информационная система почти всегда работала с нужной эффективностью. Для некоторых критически важных систем (например, систем управления) время недоступности должно быть нулевым, без всяких "почти". В таком случае говорят о вероятности возникновения ситуации недоступности и требуют, чтобы эта вероятность не превышала заданной величины. Для решения данной задачи создавались и создаются специальные отказоустойчивые системы, стоимость которых, как правило, весьма высока.
К подавляющему большинству коммерческих систем предъявляются менее жесткие требования, однако современная деловая жизнь и здесь накладывает достаточно суровые ограничения, когда число обслуживаемых пользователей может измеряться тысячами, время ответа не должно превышать нескольких секунд, а время недоступности – нескольких часов в год.
Задачу обеспечения высокой доступности необходимо решать для современных конфигураций, построенных в технологии клиент/сервер. Это означает, что в защите нуждается вся цепочка – от пользователей (возможно, удаленных) до критически важных серверов (в том числе серверов безопасности).
Основные угрозы доступности были рассмотрены нами ранее.
В соответствии с ГОСТ 27.002, под отказом понимается событие, которое заключается в нарушении работоспособности изделия. В контексте данной работы изделие – это информационная система или ее компонент.
В простейшем случае можно считать, что отказы любого компонента составного изделия ведут к общему отказу, а распределение отказов во времени представляет собой простой пуассоновский поток событий. В таком случае вводят понятие интенсивности отказов и среднего времени наработки на отказ, которые связаны между собой соотношением
Рис. 13.1.
где i – номер компонента,
λ i – интенсивность отказов,
T i – среднее время наработки на отказ.
Интенсивности отказов независимых компонентов складываются:
Рис. 13.2.
а среднее время наработки на отказ для составного изделия задается соотношением
Рис. 13.3.
Уже эти простейшие выкладки показывают, что если существует компонент, интенсивность отказов которого много больше, чем у остальных, то именно он определяет среднее время наработки на отказ всей информационной системы. Это является теоретическим обоснованием принципа первоочередного укрепления самого слабого звена.
Пуассоновская модель позволяет обосновать еще одно очень важное положение, состоящее в том, что эмпирический подход к построению систем высокой доступности не может быть реализован за приемлемое время. При традиционном цикле тестирования/отладки программной системы по оптимистическим оценкам каждое исправление ошибки приводит к экспоненциальному убыванию (примерно на половину десятичного порядка) интенсивности отказов. Отсюда следует, что для того, чтобы на опыте убедиться в достижении необходимого уровня доступности, независимо от применяемой технологии тестирования и отладки, придется потратить время, практически равное среднему времени наработки на отказ. Например, для достижения среднего времени наработки на отказ 10 5 часов потребуется более 10 4,5 часов, что составляет более трех лет. Значит, нужны иные методы построения систем высокой доступности, методы, эффективность которых доказана аналитически или практически за более чем пятьдесят лет развития вычислительной техники и программирования.
Пуассоновская модель применима в тех случаях, когда информационная система содержит одиночные точки отказа, то есть компоненты, выход которых из строя ведет к отказу всей системы. Для исследования систем с резервированием применяется иной формализм.
В соответствии с постановкой задачи будем считать, что существует количественная мера эффективности предоставляемых изделием информационных услуг. В таком случае вводятся понятия показателей эффективности отдельных элементов и эффективности функционирования всей сложной системы.
В качестве меры доступности можно принять вероятность приемлемости эффективности услуг, предоставляемых информационной системой, на всем протяжении рассматриваемого отрезка времени. Чем большим запасом эффективности располагает система, тем выше ее доступность.
При наличии избыточности в конфигурации системы вероятность того, что в рассматриваемый промежуток времени эффективность информационных сервисов не опустится ниже допустимого предела, зависит не только от вероятности отказа компонентов, но и от времени, в течение которого они остаются неработоспособными, поскольку при этом суммарная эффективность падает, и каждый следующий отказ может стать фатальным. Чтобы максимально увеличить доступность системы, необходимо минимизировать время неработоспособности каждого компонента. Кроме того, следует учитывать, что, вообще говоря, ремонтные работы могут потребовать понижения эффективности или даже временного отключения работоспособных компонентов; такого рода влияние также необходимо минимизировать.
Услуги «ИТ-инфраструктура как сервис», IaaS, становятся все популярнее у корпоративных клиентов, причем их используют уже и для критически важных задач. Настало время разобраться, что гарантируют поставщики этих услуг и какую ответственность несут в тех случаях, когда виртуальная ИТ-инфраструктура тормозит работу или вовсе становится недоступной.
Опросив ведущих поставщиков инфраструктурных сервисов IaaS корпоративного уровня, мы провели анализ их предложений. При этом под «корпоративным уровнем» понимается следующее: облачная платформа развернута в ЦОД, соответствующем требованиям Tier III (наличие сертификата от Uptime Institute не обязательно), и обеспечивает высокий уровень отказоустойчивости за счет механизмов High Availability (HA) и переезда виртуальных машин в случае аварии.
ДОСТУПНОСТЬ И ВРЕМЯ РЕАКЦИИ
Основные параметры сервиса IaaS, которые обычно указывают в соглашении SLA, - это уровень его доступности, время реакции на различные инциденты и продолжительность их разрешения, а также схема и параметры компенсации в случае простоя.
Решив воспользоваться виртуальной ИТ-инфраструктурой, можно смело рассчитывать на доступность 99,5% и выше. По крайней мере, меньшую цифру не назвал ни один из опрошенных нами провайдеров. Причем представители многих компаний подчеркнули, что указанное в их ответах значение (см. Таблицу 1) является типовым и по запросу заказчика уровень доступности может быть увеличен с помощью различных технических средств.
Обычно платформы для предоставления услуг IaaS корпоративного уровня размещаются в центрах обработки данных (собственных или внешних), соответствующих уровню отказоустойчивости Tier III, который, как известно, предполагает доступность 99,98%. Указанные провайдерами значения доступности виртуальных инфраструктур IaaS не превышают соответствующую характеристику физической площадки, что вполне естественно.
Исключение составляет доступность 99,99%, обеспечиваемая компанией Dataline в режиме метрокластера. Этот вариант катастрофоустойчивого облака охватывает два ЦОД компании - подробнее о метрокластере см. материал «Катастрофоустойчивое облако по «незаоблачной» цене», опубликованный в октябрьском номере «Журнала сетевых решений/LAN» за 2013 год ().
В принципе, поставщик может указать в SLA сколь угодно высокую доступность, хоть 100%, но тогда рискует больше потерять, чем заработать, ведь любой здравомыслящий покупатель потребует включить в договор жесткую схему компенсации за невыполнение согласованных условий. Пока какой-либо типовой схемы еще не выработано - каждый поставщик предлагает что-то свое, так что покупатель должен оценить предложенную компенсацию с учетом возможных финансовых потерь в случае простоя ИТ-сервисов.
Многие компании предлагают определенное возмещение ежемесячного платежа (в процентном соотношении) за каждый дополнительный (сверх оговоренного в SLA) час недоступности сервиса. Например, при указанном в SLA уровне доступности 99,95% (простой не более 1 часа в месяц) за каждый дополнительный час отключения от сервиса компания Inoventica готова возмещать 2% от ежемесячного платежа. Cloud4Y в стандартном варианте компенсирует 1% за 1 час простоя (при расчетах используется общая стоимость услуги за полный календарный месяц, предшествующий данному), но не более 50% стоимости услуги.
Ряд провайдеров предоставили подробные расчеты того, как размер компенсации меняется в зависимости от уровня доступности (см. Таблицу 2). В случае значительного снижения этого уровня предлагается очень существенная компенсация. Например, при значении менее 95% «Онланта» (ГК «Ланит») допускает снижение уровня оплаты услуги до 40%. А компания «ИТ-Град», если уровень доступности опустится ниже 96,71%, обещает компенсацию 50%. Ясно, что подобное ухудшение качества услуг провайдеры считают маловероятным.
«Мы ввели два самостоятельных принципа компенсации: за нарушение целевых показателей параметров услуги и целевых показателей по обработке обращений, - рассказывает Виталий Мзоков, руководитель направления «Облачные сервисы и инфраструктурные решения» из компании «Сервионика» (ГК «Ай-Теко»). - Нарушение целевых показателей параметров услуги компенсируется по прогрессивной шкале. В зависимости от фактического уровня доступности рассчитывается показатель компенсации, выражающийся в процентах от суммы счета за пользование услугой. Компенсация за нарушение целевых показателей по обработке обращений высчитывается исходя из длительности ожидания клиента с точностью до минуты».
Согласно практике, принятой в компании «Сервионика», виды обращений клиентов, а также общие целевые показатели по максимальному времени реакции на обращения и максимальному времени решения проблемы описаны в регламенте сервисного взаимодействия. А в самом договоре SLA эти показатели уточняются для конкретной услуги.
«Согласно договору, заказчик может получать у нас несколько услуг. Именно поэтому в регламенте описываются общие показатели с пометкой: «Целевые показатели, определенные в SLA на конкретную услугу, перекрывают показатели, указанные в регламенте». Это сделано для того, чтобы при необходимости можно было уточнить (расширить или уменьшить) время реакции и время решения, - поясняет Виталий Мзоков. - Мы обязаны отреагировать на обращения любого вида в течение 15 мин. Максимальное время решения, в зависимости от типа и приоритета обращения, составляет от 1 ч (для инцидентов с приоритетом № 1) до 48 ч (для обращений, по которым требуется полная проработка информационного запроса заказчика - например, предоставление информации по тарифам и другим услугам, различные уточнения и инструктажи).
Время реакции на заявку обычно зависит от ее приоритетности. Вот, например, какие уровни приоритета практикует компания Linxdatacenter:
- Critical - сервис недоступен полностью, необходимо принять срочные меры по восстановлению, время реакции 15 мин, время восстановления не более 4 ч;
- High - сервис недоступен частично, время реакции до 1 ч, повышенный приоритет;
- Normal - уточнение по параметрам сервиса, текущие несрочные вопросы, время реакции до 1 ч, на подготовку ответа отводится 24 ч.
В Таблице 3 показан еще один пример - разделение запросов по категориям, применяемое компанией Cloud4Y; время реакции - не более 30 мин.
Оперативно стараются работать в T-Systems. Как сообщил Всеволод Егупов, директор по продажам ICT-направления T-Systems RUS, специалисты этой копании «в 80% случаев реагируют в течение 30 с» (!). Но, как и большинство наших респондентов, он отметил, что время реакции зависит от критичности ситуации.
ИНСТРУМЕНТЫ МОНИТОРИНГА
Мало указать в договоре SLA привлекательный уровень доступности и жесткие схемы компенсаций, надо еще предоставить клиенту удобный и эффективный инструмент контроля. И здесь подходы поставщиков существенно различаются.
Ссылаясь на практику компании «Сервионика», Виталий Мзоков отмечает, что клиенты больше заинтересованы в получении от оператора прозрачной и точной отчетности, чем в освоении каких-то особых инструментов для самостоятельного мониторинга. Как правило, «Сервионика» ежемесячно предоставляет отчеты по согласованному набору параметров, но, по желанию клиента, контрактом может предусматриваться и более частая отчетность.
Многие компании, по умолчанию, предоставляют отчеты о состоянии работоспособности сервиса раз в месяц, но могут и чаще - по запросу клиентов. Пример отчета, предлагаемого компанией «Онланта», показан на Рисунке 1. Как утверждает Михаил Ляпин, руководитель ее облачного направления, «Онланта» - единственная в России компания, предоставляющая заказчикам отчет о доступности облачных ресурсов с таким уровнем детализации. По его данным, большинство сервис-провайдеров обходятся статистикой по уровню доступности виртуальных машин.
Ряд компаний предлагают клиентам воспользоваться консолью самообслуживания в онлайновом режиме. По словам Руслана Заединова, заместителя генерального директора, руководителя направления ЦОД и облачных вычислений компании «Крок», у каждого потребителя услуги IaaS есть доступ к такой консоли с встроенной возможностью онлайн-мониторинга функционирования тех или иных составляющих. Например, в случае виртуальных машин ИТ-специалисты заказчика могут проконтролировать, насколько загружен процессор, как работает ввод-вывод, сколько памяти занято и пр. Эти данные доступны в режиме реального времени, а также - по запросу - в виде статистики за любой период.
НАДО ЛИ ГАРАНТИРОВАТЬ ПРОИЗВОДИТЕЛЬНОСТЬ
Очевидно, что при росте нагрузки на IaaS-платформу провайдера возможна деградация уровня производительности виртуальной машины. Поставщики услуг всячески стремятся не допустить такого развития событий. В этом солидарны все компании. Однако некоторые включают параметры производительности в SLA, а другие считают подобную меру ненужной.
Вот что говорит по этому поводу Виталий Слизень, член совета директоров Inoventica: «Мы не наблюдаем деградации [производительности] даже при росте нагрузки, так как своевременно производим расширение и модернизацию мощностей дата-центров. Отдельно в SLA данные параметры (производительность ВМ и СХД) не отражены, поскольку их соблюдение является нашей первостепенной обязанностью, независимо от обращений клиентов». Специалисты Inoventica осуществляют постоянный мониторинг всех основных параметров арендованных инфраструктурных мощностей, что позволяет им оперативно получать информацию о потенциальных проблемах и своевременно их прогнозировать.
Об отсутствии деградации говорит и Игорь Дроздов, менеджер технической поддержки продаж Linxdatacenter: «Наша компания предоставляет в пользование гарантированные вычислительные ресурсы. Они зарезервированы в облаке и расширяются по мере увеличения числа клиентов, поэтому производительность виртуальных машин и СХД остается на стабильно высоком уровне. Кроме того, мы производим своевременную модернизацию серверов и выполняем мониторинг производительности при помощи специализированных продуктов VMware».
Компания Orange Business Services тоже относится к числу сервис-провайдеров, не регламентирующих в стандартном SLA параметры производительности. При этом, как отмечает Дмитрий Дородных, руководитель отдела развития продуктов унифицированных коммуникаций и ИТ Orange Business Services в России и СНГ, «если клиент требует, чтобы для его виртуальных машин гарантированно выделялись определенные вычислительные ресурсы, мы применяем стандартные средства современных платформ виртуализации, которые при возникновении конкуренции за ресурсы позволяют переместить виртуальные машины на другие серверы».
Всеволод Егупов считает, что вносить характеристики производительности в SLA «не имеет смысла, так как деградация сказывается на уровне доступности сервиса, регулируемом соглашением». В T-Systems производительность виртуальных машин и СХД контролируется департаментом по управлению мощностями, его специалисты отвечают за недопущение ее деградации.
Немало и компаний, которые полагают, что внесение в SLA характеристик производительности целесообразно. Самым узким местом виртуализированной ИТ-среды многие эксперты считают производительность системы хранения, поэтому большинство поставщиков уделяют наиболее пристальное внимание таким характеристикам СХД, как количество операций ввода-вывода в секунду (IOPS) и время доступа к диску (latency).
Dataline указывает метрики производительности СХД и виртуальных машин в каждом SLA (см. Таблицу 4). При этом, как отмечает Дмитрий Тишин, руководитель отдела развития услуг этой компании, «в зависимости от требований, выдвигаемых к системному ландшафту со стороны клиента, метрики могут быть изменены». Значения IOPS измеряются системой мониторинга NetApp DFM, а время доступа к диску - штатными средствами ПО виртуализации (vCenter). В случае возникновения проблем с виртуальной машиной дежурная смена и инженеры группы виртуализации получают соответствующее предупреждение. Кроме того, Dataline обеспечивает мониторинг различных параметров на уровне операционной системы и запущенных в ней сервисов. Если клиент пользуется сервисом компании по администрированию ОС и сервисов, такой мониторинг осуществляется по умолчанию.
Для недопущения деградации производительности виртуальных машин специалисты Dataline применяют комплекс мер. Так, для кластера используется механизм Distributed Resource Scheduler (DRS), который отслеживает загрузку физических серверов по основным параметрам, - в случае достижения определенной нагрузки на сервер часть виртуальных машин автоматически перемещается на другой. В кластере поддерживается избыточность серверов с таким расчетом, чтобы нагрузка на весь кластер составляла не более 70%. В рамках заключенных сервисных контрактов с поставщиками оборудования ресурсные мощности кластеров можно наращивать по плану-графику.
Компания Safedata тоже регламентирует в SLA такие характеристики производительности, как IOPS и MIPS. «Снизить производительность ниже указанных в SLA значений мы не можем, - рассказывает Антон Антонов, начальник отдела продаж Safedata. - Если при повышении нагрузки на физических серверах наблюдается деградация сервиса, вводятся в строй дополнительные резервные хосты EXSi».
Регламентируемые в SLA Cloud4Y характеристики производительности дисковой системы СХД указаны в Таблице 5. Как сообщил Евгений Бессонов, руководитель отдела маркетинга Cloud4Y, в случае нарушения гарантированных показателей производительности CPU, HDD, RAM предусматривается компенсация, которая оговаривается отдельно или выплачивается в соответствии со стандартными условиями: 1% от месячной стоимости за 1 ч.
«Мы гарантируем обеспечение производительности виртуальных машин по нижней границе, не ограничивая ее сверху, - рассказывает Руслан Заединов. - Таким образом, если на сервере, где расположена виртуальная машина, имеются свободные вычислительные ресурсы сверх гарантированных, они будут доступны заказчику». Что касается СХД, то в настоящее время все клиенты «Крок» пользуются общим каналом связи с системами хранения. Долгое время это не вызывало проблем, но сейчас, чтобы удовлетворить растущие потребности заказчиков, компания переводит облачные СХД с дисков Fibre Channel и SATA на флэш-накопители с прямым доступом к ним из виртуальных машин через сеть Infiniband. Параллельно внедряется ПО для обеспечения гарантированной пропускной способности системы хранения данных в облаке. Соответствующие изменения в SLA будут внесены уже этой осенью.
По согласованию с заказчиком компания «Сервионика» фиксирует в SLA каждого проекта показатели производительности отдельных компонентов облачной платформы. Кроме того, в соглашении указываются способы измерения этих показателей и периодичность проводимых измерений. «Написать «гарантируется 100 500 OPs на 1 Гбайт дискового пространства» может любой оператор, но далеко не все способны доказать, что этот критерий выдержан. Мы за максимально прозрачные отношения между оператором облачной платформы и ее потребителем», - подчеркивает Виталий Мзоков. Производительность виртуальных машин и СХД определяется в SLA «Сервионика» показателями IOPS и Latency.
Как рассказал Максим Захаренко, генеральный директор сервис-провайдера «Облакотека», в заключаемых ими договорах пиковые показатели производительности регламентируются таким образом, чтобы загрузка пропускной способности ввода-вывода и сети не превышала 80%. Мониторинг осуществляется с помощью системы Microsoft SCOM. Он отмечает, что для разных систем важны различные показатели: для Web-сайтов - время отклика, для размещения ИТ-инфраструктур - показатели пиковой загрузки процессора, памяти, виртуальной сети и т. д. В свой SLA эта компания включает также параметры гарантированного резервного копирования, способы и сроки предоставления и хранения пользовательских данных («Честное расставание»).
СКВОЗНЫЕ SLA
Сколь бы ни была высока надежность самой платформы IaaS, размещенной в отказоустойчивом ЦОД, узким для заказчика местом могут стать каналы доступа к этой платформе. Хорошей новостью является то, что многие из опрошенных нами провайдеров практикуют заключение сквозных SLA, охватывающих как сам сервис IaaS, так и каналы доступа. При этом, по их утверждению, при правильной организации и резервировании каналов уровень доступности связи оказывается не ниже, чем у платформы SLA, а потому в сквозных SLA эта важная характеристика не снижается.
Впрочем, как замечает Всеволод Егупов, снижение или сохранение уровня доступности зависит от способа организации каналов связи - если канал зарезервирован, доступность не ухудшается. В ином случае уровень доступности в сквозном SLA снижается до уровня доступности канала. У компании T-Systems RUS имеется собственная сеть центров обработки данных, расположенных по всему миру. Обслуживание российских клиентов в основном осуществляется из центров обработки данных, которые находятся в Германии и Австрии. У компании подписано SLA с «Ростелекомом», «Билайном», сотрудничает она и с другими операторами связи.
Те поставщики услуг IaaS, которые являются одновременно и операторами связи, используют это преимущество. Так, будучи международным оператором связи, Orange Business Services практикует заключение сквозных SLA, охватывающих IaaS и услуги связи. Уровень доступности в таких SLA - 99,95%. Но, как поясняет Дмитрий Дородных, эта характеристика зависит от географического местонахождения клиента - например, в Центральном регионе этот уровень выше, чем за Уралом и в Сибири. Для «последней мили» могут быть свои параметры SLA. Схемы и механизмы контроля SLA на каналах связи за десятилетия уже отработаны, поэтому вопрос мониторинга не является для Orange Business Services проблемой.
Как отмечает Виталий Слизень, Inoventica располагает своими магистральными каналами связи и географически распределенной сетью ЦОД, благодаря чему становится возможна реализация геокластеров. Это позволяет сохранить данные и работоспособность сервисов даже в случае физического разрушения одного из ЦОД. По его сведениям, Inoventica - «единственная компания на российском рынке, предоставляющая полную цепочку услуг «ЦОД – канал – сервис – клиент (АРМ)» в соответствии со SLA, которым предусматриваются минимальная за держка при передаче пакетов (round trip delay) менее 10 мс и почти нулевая потеря пакетов». В настоящее время комплексное решение Inoventica доступно клиентам в пяти федеральных округах РФ.
Поставщики услуг IaaS, не являющиеся операторами связи, активно сотрудничают с таковыми. Так, «Сервионика» сформировала SLA для работы с операторами связи, обслуживающими ее ЦОД (а это более 10 крупных телеком-провайдеров). Условия этих SLA компания транслирует в договорах с клиентами, которые пользуются услугами связи. А контроль за соблюдением SLA обеспечивают технические службы ЦОД «ТрастИнфо». «Мы указываем в наших контрактах те же параметры SLA, что и у операторов, - то есть берем на себя ответственность за качество их работы и бесперебойное предоставление каналов связи», - отмечает Виталий Мзоков.
Для предоставления клиентам каналов связи Dataline практикует использование услуг телекоммуникационных операторов по схеме субподряда. При такой схеме компания контролирует качество в рамках своего договора с оператором, клиент же получает от нее комплексную услугу и имеет дело только с одним контрагентом. Уровень доступности такой комплексной услуги не снижается. У Dataline имеется собственная сеть передачи данных в Москве, где гарантируются следующие характеристики: доля потерянных пакетов - не более 0,2%, средняя задержка в сети - не более 5 мс.
Как утверждает Руслан Заединов, «Крок» использует широкие каналы, пропускной способности которых вполне хватает на всех заказчиков в облаке. Технически действующие гарантии обеспечиваются перекрестным резервированием каналов между разными ЦОД «Крок» при помощи собственного оптического кольца. Для тех организаций, для которых критична фиксированная пропускная способность канала связи, компания реализует индивидуальное подключение к облаку по отдельным каналам с гарантированной пропускной способностью или даже по «темной» оптике. Такое подключение чаще всего оснащается индивидуальными средствами шифрования, в том числе сертифицированными.
Итак, услуги IaaS предлагаются в России довольно большим числом компаний, причем по вполне понятным и документированным (в SLA) правилам. В отрасли еще не пришли к согласию относительно того, надо ли регламентировать в SLA характеристики производительности виртуальных ИТ-инфраструктур, но гарантируемые показатели доступности выглядят вполне приемлемыми даже для самых требовательных корпоративных заказчиков. К тому же провайдеры понимают потребность заказчиков в сквозных SLA и работают над их совершенствованием.
Александр Барсков - ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу:
Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.
Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:
| Доступность | Время простоя в месяц | Время простоя в год |
| 90% | 3 дня | 37 дней |
| 98% | 14,6 часов | 7,3 дня |
| 99% | 7,3 часа | 3,7 дней |
| 99,8% | 1,5 часа | 18 часов |
| 99,9% | 44 минуты | 8.8 часов |
| 99,99% | 4.4 минуты | 53 минуты |
| 99,999% | 26 сек | 5,3 минуты |
Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.
Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.
Наверное, существуют интернет-проекты, которые могут пережить и 37 дней простоя в год (больше месяца!). Но всё-таки большинство интернет-магазинов, порталов и сайтов (в особенности тех, чьи транзакции проходят через сайт) не могут себе позволить такой роскоши, как даже 18 часов в год. Репутацию восстановить сложно всегда, а если она теряется по причинам “у системного администратора выходной” это и вовсе обидно.
“Пять девяток” — вот, что такое высокая доступность
Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.
Высокая доступность нужна всем
Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.
Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.
Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.
Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.
Немного о том, из чего складывается высокая доступность
Доступность может быть сетевая и сервиса.
Сетевая доступность
— это когда ваш сервер доступен по сети.
Доступность сервиса
— это когда ваш сервер может обслуживать клиентов.
Доступность сервиса не может быть лучше сетевой доступности, если вы не используете альтернативных подключений (со своей сетевой доступностью).
Доступность сервиса зависит от:
- сетевой доступности вашего сервера
- скорости реакции вашего админа на проблему
- скорости реакции поддержки дата-центра на проблему
- скорости замены неисправного железа в дата-центре
Недоступность складывается из:
- проблем сетевой доступности
- проблем с “железом”
- проблем с нагрузкой на сервере (“тормозит”, не справляется)
- программных ошибок (“косяки” программистов)
И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.
Если вам нужна гарантированная доступность выше 99,8%, необходимо заниматься отказоустойчивостью. И сервер должен быть не один. Но это тема отдельного разговора.
|Масштабируемость и высокая доступность становятся всё более популярными с увеличением спроса на надежные и производительные инфраструктуры, предназначенные для обслуживания критически важных систем. Уменьшение времени простоя и устранение единых точек отказа – такие же важные проблемы, как и обработка повышенной нагрузки на систему. Высокая доступность (high availability) – качество инфраструктуры, способное устранить их.
Данная статья рассказывает, что именно значит термин «высокая доступность» и как это качество может сделать инфраструктуру более надёжной.
Высокая доступность
В программировании термин «доступность» (availability) используется для описания интервала времени, в течение которого сервис доступен, а также времени, необходимого системе для ответа на запрос пользователя. Высокая доступность – это качество системы или компонента, которое обеспечивает высокий уровень эксплуатационных характеристик за определенный период времени.
Измерение доступности
Доступность часто выражается в процентах, что обозначает уровень аптайма, который ожидается от конкретной системы или компонента за конкретный период времени. В таком случае 100% доступности значит, что система никогда не выходит из строя; соответственно, система, которая обеспечивает 99% доступности в течение одного года, может иметь до 3,65 дней простоя (1%).
Эти значения вычисляются на основе нескольких факторов, включая плановое и внеплановое техническое обслуживание, а также время, необходимое для устранения возможного сбоя системы.
Как работает высокая доступность?
Высокая доступность используется в качестве механизма быстрого реагирования на сбои. Этот механизм довольно прост, но, как правило, требует специализированного программного обеспечения и конфигурации.
Когда необходима высокая доступность?
Минимизация времени простоя и перебоев в обслуживании очень важна при создании отказоустойчивых систем для производства. Независимо от того, насколько надежно системное и программное обеспечение, в системе могут возникнуть проблемы, которые приведут к сбою в работе приложения или сервера.
Внедрение высокой доступности инфраструктуры – хорошая стратегия для снижения вероятности возникновения и минимизации влияния этих событий. Высоко доступные системы могут автоматически выполнить восстановление сервера или компонента после сбоя.
Что делает систему высоко доступной?
Одной из целей высокой доступности является устранение единых точек отказа в инфраструктуре. Единая точка отказа – это компонент стека, отказ которого выводит из строя всю систему или вызывает недоступность данных; то есть любой компонент, который является необходимым условием для работы приложения, считается единственной точкой отказа.
Чтобы устранить единые точки отказа, нужно подготовить каждый слой стека к избыточности. Для примера давайте представим, что у вас есть инфраструктура, состоящая из двух одинаковых избыточных веб-серверов с балансировщиком нагрузки. Трафик, поступающий от клиентов, будет равномерно распределен между веб-серверами, но если один из серверов выйдет из строя, балансировщик нагрузки будет перенаправлять весь трафик на оставшийся веб-сервер.
В данной ситуации веб-сервер не является единой точкой отказа, потому что:
- В кластере существует «запасной» компонент, способный взять на себя все задачи.
- На другом уровне существует механизм (балансировщик нагрузки), способный обнаруживать сбои в компонентах и адаптировать свое поведение для своевременного восстановления работы приложения.
Но что если из строя выйдет балансировщик нагрузки?
В описанном сценарии (который довольно часто встречается) единой точкой отказа является именно балансировщик нагрузки.
Устранить эту точку отказа не так уж просто. Конечно, можно легко настроить дополнительный балансировщик нагрузки для обеспечения избыточности, однако в системе уровнем выше балансировщиков нагрузки не существует компонента, который мог бы взять на себя обнаружение сбоя и восстановление работы.
Одна только избыточность не может гарантировать высокой доступности.
Для обнаружения и устранения сбоев в инфраструктуре должен существовать специальный компонент.
Обнаружение и устранение сбоев можно реализовать методом top-to-bottom: верхний слой отслеживает сбои нижнего слоя. Вернёмся к нашему примеру; в таком кластере балансировщик нагрузки – это верхний слой. Если один из веб-серверов (нижний слой) станет недоступным, балансировщик нагрузки перестанет перенаправлять на него запросы.
Такой подход достаточно прост, но он имеет свои ограничения: в инфраструктуре всегда будет точка, для которой верхний слой отсутствует либо недоступен (как в случае с балансировщиком нагрузки). Создание сервиса обнаружения неисправностей для балансировщика нагрузки на внешнем сервере равно созданию новой единой точки отказа.
При таком сценарии необходим распределенный подход. Нужно соединить в кластер несколько дублирующих нод, где каждая нода будет в равной степени способна к обнаружению и устранению сбоя.
Однако в случае с балансировкой нагрузки есть дополнительная сложность, связанная с работой серверов имен. Восстановление после сбоя балансировки нагрузки, как правило, означает переход балансировки на другой (избыточный) ресурс, а для этого нужно изменить DNS (указать доменное имя или IP-адрес резервного балансировщика нагрузки). Такие изменения могут занять значительное количество времени и повлечь за собой большой период простоя.
В такой ситуации можно использовать балансировку по алгоритму round-robin. Однако этот подход не является надежным, поскольку аварийное переключение будет на клиентской стороне приложения.
Более надёжным и отказоустойчивым решением являются системы, поддерживающие гибкие ip-адреса. При необходимости IP-адрес модифицируется, что препятствует распространению неисправности и её кэшированию. При этом доменное имя может оставаться связанным с тем же IP-адресом, а сам IP-адрес перемещается между серверами.
Какие компоненты необходимы для поддержки высокой доступности?
Для настройки высокой доступности необходимо установить несколько системных компонентов. Однако гораздо сильнее высокая доступность зависит от таких факторов:
- Окружение: если все серверы кластера расположены в одной географической области, внешние условия (землетрясения, наводнения и т.п.) могут привести к полному сбою системы. Наличие серверов в разных датацентрах и географических областях повысит отказоустойчивость.
- Аппаратное обеспечение: высоко доступные серверы должны быть устойчивы к перебоям в подаче электроэнергии и сбоям оборудования, включая жесткие диски и сетевые интерфейсы.
- Программное обеспечение: весь программный стек (в том числе операционная система и само приложение) должен быть готов к обработке случайных сбоев, которые могут потребовать перезапуска системы.
- Данные: потеря и несоответствие данных может быть обусловлено несколькими факторами. Высоко доступные системы должны принимать во внимание необходимость защиты данных на случай сбоя.
- Сеть: незапланированные отключения сети представляют собой еще одну возможную точку отказа для высоконадежных систем. Важно иметь на такой случай запасную стратегию сети.
Какое программное обеспечение необходимо для высокой доступности?
Каждый слой системы с высокой доступностью будет иметь разные потребности. На уровне приложения балансировка нагрузки является неотъемлемым компонентом в системе с высокой доступностью.
(High Availability Proxy) – популярное средство для настройки балансировки нагрузки, так как позволяет обрабатывать нагрузку на нескольких уровнях, а также для различных видов серверов, включая серверы баз данных.
Также в системный стек важно внедрить надёжное средство для точки входа в приложение. Чтобы устранить единую точку отказа, как упоминалось ранее, необходимо реализовать кластер балансировки нагрузки с гибкими IP-адресами. Для создания таких систем используются Corosync и Pacemaker.
Заключение
Высокая доступность – очень важный аспект надёжности инфраструктуры, ориентированный на обеспечение высокого уровня эксплуатационных характеристик в течение определенного периода времени. На первый взгляд реализация высокой доступности может показаться довольно сложной, однако она может принести много пользы системе, требующей повышенной надежности.
Tags:
