OSS Practice

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

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

• Насколько доступность данных критична для работы компании? Как долго компьютерные данные могут оставаться недоступными без каких-либо последствий для репутации компании, бизнеса?
• Какие денежные средства компания готова выделить на приобретение и поддержку системы?

Ответив на эти вопросы можно определить тип создаваемой системы:

Приведем примеры соответствия:

Основные понятия, используемые при рассмотрении надежности СУБД:

Отказоустойчивость — способность к восстановлению работы приложений и данных после сбоя. Причиной отказа могут служить аппаратная неисправность, проблемы программного обеспечения, неправильные действия пользователей.

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

При проектировании надежной системы необходимо понимать причины отказа, от которых необходимо защититься:

• Физическое разрушение линий связи
• Сбой аппаратной части
• Нештатная работа ПО
• Нештатная работа персонала
• Падение под нагрузкой

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

1. Потеря связи с сервером БД и/или Физический отказ сервера

   Потеря связи с сервером является настолько же критичной, как и физический отказ сервера, так как в любом случае сервер недоступен для использования.

   Для создания надежной инфраструктуры необходимо обеспечить как катастрофоустойчивость, так и отказоустойчивость инфраструктуры.

   При использовании одного сервера катастрофоустойчивость сводится к нулю, отказоустойчивость также невысока.

   Для обеспечения отказоустойчивости единственно верным способом является повышение надежности аппаратной части, разделение самой базы данных (хранилище) и сервера СУБД.

   

   Количество серверов и хранилищ данных зависит от размера и важности базы, однако в основе любой отказоустойчивой инфраструктуры должно соблюдаться такое разделение. Для обеспечения высокой отказоустойчивости необходимо использование более чем одного сервера. В связи с этим все рассматриваемые далее решения рассчитаны, как минимум, на две машины, объединенные в сеть / кластер.

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

   Для обеспечения же отказоустойчивости инфраструктуры необходимо комбинировать аппаратные и программные средства. Рассмотрим их отдельно.

   Особенности использования аппаратных средств для обеспечения надежности СУБД:

   • все операции производятся параллельно на одинаковых компонентах, а затем результат логически сравнивается, что помогает выявить ошибки;
   • в случае выхода из строя какого-либо компонента ее «дублер» продолжает работу.

   Особенности использования программных способов для обеспечения надежности СУБД:

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

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

   1. При строительстве обычной по надежности СУБД возможно использование наименее затратного метода резервирования данных – «холодного». Он требует периодической остановки сервера для создания с него копии на резервную машину. При отказе сервера, начинает работать «холодный». Но этот метод не дает полное восстановление базы и требует времени (от нескольких минут до нескольких часов) для запуска сервера в качестве основного.

      

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

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

   • Режим максимальной защиты
   • Режим максимальной доступности
   • Режим максимальной производительности

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

   Перейдем к рассмотрению аппаратных средств обеспечения надежности. Выделим два ключевых средства, которыми достигается надежность хранения данных:

   • RAID — для обеспечения отказоустойчивости
   • Распределенные СХД — для обеспечения катастрофоустойчивости

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

   Для обеспечения катастрофоустойчивости системы, состоящей из нескольких серверов, принято использовать распределенные системы хранения данных. Их сравнение также приведено в таблице ниже.

   Наиболее простым и дешевым вариантом является DAS/SAS. Он не гарантирует постоянный доступ к базе, так как в этом случае СХД напрямую соединяется с сервером. Поэтому его использование рекомендуется при построении системы, состоящей из одного сервера.

   

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

   

   SAN является наиболее дорогой и сложной в обслуживании СХД. При этом это единственный вариант, позволяющий построить распределенную систему без потерь в скорость передачи данных.

   

   RAID (обеспечение отказоустойчивости):

   Методы	Стоимость (избыточность дисков, шт.)	Надежность (Количество допустимых падений), n — количество зеркал
   RAID1	2n	n-1
   RAID5	n+1	1
   RAID6	n+2	2
   RAID10	2n	n-1
   RAID50	n+1	1

   СХД (обеспечение катастрофоустойчивости):

   Методы	Простота развертывания	Простота использования	Консолидация ресурсов	Возможность масштабирования	Стоимость	Распределенная СХД	Скорость передачи данных	Надежность
   SAN	-	+	+	+	Высокая	+	+	Высокая
   NAS	+	+	+	+	Низкая	+	-	Средняя
   DAS/SAS	+	-	-	-	Низкая	-	+	Низкая

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

2. Нештатная работа ПО и персонала

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

   Рассмотрим способы восстановления базы при ее повреждении:

   • Восстановление из резервной копии базы
   • Восстановление по журналу транзакций

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

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

В разделе «Отказоустойчивость» мы не будем рассматривать способы защиты от всевозможных воздействий человека на базу (SQL-инъекции, недобросовестный администратор и другие), это будет рассмотрено в разделе «Безопасность».

3. Падение под нагрузкой

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

   • DDoS-атаки
   • Постоянная перегрузка сервера из-за возросшего числа пользователей
   • Периодическая перегрузка сервера из-за пиковых нагрузок

   Развитие событий при первом варианте мы рассмотрим в разделе «Безопасность».

   При увеличении нагрузки на сервер существуют различные варианты решения проблем:

   1. Масштабирование базы
   2. Оптимизация работы СУБД
   3. Динамическое подключение серверов при пиковой нагрузке

   Эти возможности будут рассмотрены в разделе «Масшабирование» документа.

Реализация методов в различных СУБД

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

• MySQL

  Для создания отказо- и катастрофоустойчивой базы в MySQL используется MySQL Cluster NDB. Важными особенностями данной системы являются работа с недорогими аппаратными средствами и отсутствие каких-либо специфических требований к аппаратным ресурсам или программному обеспечению.

  MySQL Cluster NDB позволяет организовать как «холодное», так и «горячее» резервирование. Также данная система реализует асинхронные мульти-мастерные репликации. Все функции осуществляются на основе стандартных средств MySQL через скрипты и изменение файлов конфигураций, либо через стороннее программное обеспечение, такое как DRBD (например, для создания мульти-мастерной репликации).

  К минусам данной технологии относятся проблемы, которые могут возникнуть при «горячем» резервировании в MySQL, а также отсутствие возможности создания надежной синхронной мульти-мастерной репликации. Это связано с особенностями реализации некоторых функций (н-р, реализация двух-фазного завершения), использование которых приводит к рассогласованности между серверами кластера. Подобные проблемы вызваны тем, что MySQL Cluster NDB появился относительно недавно и, вероятно, они будут решены в дальнейшем. Еще одним недостатком является сложность и неочевидность реализации всех вышеназванных методов.

• Oracle

  Технология Real Application Cluster позволяет организовать распределенную отказоустойчивую систему любого типа. Единственным минусом Oracle RAC является сложность процесса настройки кластера высокой надежности.

• DB2
• MSSQL
• EnterpriseDB