Инженерная инфраструктура центров обработки данных (ЦОД)

Работая в Майкрософт, я вел серию еженедельных ток-шоу под названием Enterprise Computing Series (ECS), где обычно организовывал беседы на тему серверов и крупномасштабных сервисов. Я сказал “обычно”, потому что ток-шоу иногда настолько отклонялись от темы, что их участником мог быть бывший член команды Ferrari Formula 1. Иногда во время ток-шоу обсуждались темы, предложенные клиентами, потому что мне либо очень нравилась работа или технология, либо, по моему мнению, это была широко распространенная тема.

     У Enterprise Computing Series интересная история. Она была создана Джимом Грэем в Tandem. Пэт Хэлланд стал ведущим после Джима и вел ее, пока не перешел в Hal Computer Systems Энди Хеллера. Он продолжал ECS в HAL, а потом принес ее вместе с собой в Майкрософт, где он продолжал ее вести на протяжении многих лет. Со временем Пэт передал ее мне, и я сам вел ECS в течение 8 или 9 лет до перехода в Amazon Web Services. По иронии судьбы, когда я пришел в Amazon, я узнал, что Пэт Хэлланд снова создал серию ток-шоу тематически похожую на ECS, и назвал ее Principals of Amazon (PoA).

     PoA представляет собой отличное ток-шоу, но не включает сторонних докладчиков и проводится в определенный день недели, поэтому мне время от времени попадаются темы, которые я хотел бы представить в Amazon, но которые не подходят для PoA. По этим причинам Enterprise Computing Series продолжает существовать!

     В этом выпуске ECS Ашраф Абулнага из университета Ватерлоо представлял тему Высокий уровень доступности систем баз данных в облачных вычислительных средах. Ашраф представлял две темы, 1) RemusDB: обеспечение высокого уровня доступности баз данных с помощью технологии виртуализации и 2) DBECS: обеспечение высокого уровня доступности баз данных с использованием эвентуально унифицированных облачных хранилищ данных. Первая тема основывалась на работе Умара Фарука Минха, Шрирама Раджагопалана, Брендана Кулли (Brendan Cully), Ашрафа Абулнага, Кена Салема и Эндрю Уорфилда “RemusDB: прозрачный высокий уровень доступности для систем баз данных”, которая получила премию VLDB 2011 Best Paper Award. Вторая тема основывалась на работе, которая еще не была опубликована и не была полностью закончена.

     Сосредоточившись на этой первой работе, они создали систему баз данных типа активный/резервный с помощью Remus. Remus реализует прозрачный высокий уровень доступности для Xen VM. Он делает это с помощью отражения всех записей в память активной виртуальной машины (VM) в неактивной, резервной VM. Remus держит резервную VM в состоянии готовности для принятия управления с точно таким же состоянием памяти как у основного сервера. При перехвате управлении она сможет сделать это с таким же самым содержанием памяти, включая кэш.

     Remus представляет собой простой и удобный метод очень быстрого перехвата управления от основной VM. Проблема заключается в том, что задержки записи в память составляют часть сетевых задержек, поэтому любое решение, которое превращает задержки записи в память в сетевые задержки записи просто не будет адекватно работать для большинства рабочих нагрузок. Remus устраняет эту проблему с использованием ожидаемого решения: передает большое количество запросов в одном сетевом пакете. По умолчанию, каждые 25 миллисекунд Remus приостанавливает работу основной VM, копирует все измененные страницы в буфер Dom0 (гипервизор) и возобновляет работу виртуальной машины. Буфер Dom0 используется для того чтобы свести до минимума период времени, на который необходимо приостанавливать работу VM, но при этом требует объема памяти Dom0 достаточного для наибольшей группы измененных страниц за 25 миллисекунд.

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

     Недостатки технологии Remus состоят в следующем: 1) может требоваться буфер dom0 довольно большого размера и 2) до 25 миллисекунд рабочего времени может быть потеряно на перехват управления, 3) точка контрольной разгрузки требует расхода большого количества ресурсов, включая время. Время копирования измененных страниц может быть приемлемым, но остальные накладные расходы могут быть достаточно высокими, и могут сильно затруднять функционирование рабочих нагрузок, обращающихся к хосту, типа баз данных в Remus.

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

• Асинхронное сжатие контрольной точки: поддерживать LRU-буфер недавно использовавшихся страниц и отправлять только разность этих страниц. Эта оптимизации основана на допущении, что системы БД часто изменяют некоторые страницы и, как правило, изменяют только небольшую часть этих страниц между контрольными точками.
• Отслеживание считываний диска: не помечать страницы, считанные с диска, как ожидающие записи, так как они уже доступны для резервного сервера через посредство устройств ввода-вывода.
• Снятие защиты памяти: позволяет БД объявлять области памяти, которые не требуют репликации. Эта оптимизация оказалась не такой эффективной как другие оптимизации и, кроме того, она требовала изменений механизма БД.
• Оптимизация сети/фиксация транзакции: Remus помещает в буфер все исходящие сетевые пакеты, для того чтобы клиенты никогда не могли видеть результаты небезопасного выполнения, но это увеличивает задержку, не позволяя отправлять клиенту никаких ответов, пока не будет достигнута следующая контрольная точка Remus. Поскольку БД могут отказывать и транзакции могут аварийно прекращаться, оптимизация БД состоит в отправке всех пакетов клиенту в реальном масштабе времени, за исключением операций изменения состояний фиксации, аварийного прекращения или других транзакций БД. При перехвате управления в любом клиенте в незащищенном состоянии сети (изменения отправлялись с последней контрольной точки) транзакция не будет выполнена. Правильный клиент будет перезапускать операцию и продолжать работать без проблем.

     Вот что было достигнуто в Remus: защита быстрого перехвата управления для БД и значительное снижение накладных расходов на репликацию. Авторы использовали стандарт TPC-C (Совет по обработке транзакций СУБД) для доказательства того, что оптимизация СУБД в Remus позволяет сохранять все его (Remus) функции защиты, но снижать накладные расходы приблизительно до 1/10.

     Ссылка автора:

• Слайды презентации: http://mvdirona.com/jrh/TalksAndPapers/AshrafAboulnaga20111114.pdf
• Статья: http://www.cs.uwaterloo.ca/~ashraf/pubs/pvldb11remusdb.pdf

     Я не на 100% убежден в том, что Remus является лучшим решением проблем для баз данных с высокой доступностью, но мне нравится это решение, изученное из предложенных организациями. Спасибо Pradeep Madhavarapu, кто руководит частью инженерной команды по разработке ядра база данных Amazon (и нанятый ) для организации этого разговора с Ashraf Aboulnaga, кто делает данное решение.

Автор статьи: James Hamilton,  член команды Amazon Web Services

Статья опубликована с разрешения автора.

Оригинал статьи находится: http://perspectives.mvdirona.com/2011/11/27/HighAvailabilityForCloudComputingDatabaseSystems.aspx

Блог James Hamilton: http://perspectives.mvdirona.com