Физические против Логических катастроф

Прежде всего, существует различие между RPO / RTO для физических и логических катастроф - или иначе, недоступности данных по сравнению с потерей данных. Объясню на основе нескольких примеров:

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

Это логическая катастрофа, которая приводит к недоступности данных.

Логические катастрофы не требуют дополнительных центров обработки данных с дополнительным оборудованием для восстановления данных. Если вы каким-то образом делаете частые копии данных (обычно известно как стратегия "Backup", хотя и более инновационные и элегантные пути становятся доступными), то вы можете восстановиться локально.

Физические катастрофы требуют наличия второго (запасного) центра обработки данных с соответствующим оборудованием, чтобы иметь возможность восстановиться, по крайней мере, если вы не можете уладить возникшую проблему в течение многих часов или даже дней, чтобы вернуться к работе он-лайн. Резервный центр обработки данных должен иметь доступ локально к некоей правильной, свежей копии данных, потому что одного только оборудования недостаточно, чтобы иметь возможность восстановиться.

Давайте пока сосредоточимся на физических катастрофах.

Нулевые потери данных - Нулевое время простоя

Что касается RTO, некоторые последние инновации (истинно активный/активный растянутые кластеры) позволяют выжить при физических катастрофах даже без необходимости перезагрузки или восстановления базы данных. Но для этого необходимо дорогостоящее программное обеспечение кластеризации, некоторые дополнительные аппаратные средства и межсоединения с низким временем задержки, и сегодня это решение не всегда покрывает серверы приложений, так что всё еще может быть некоторое влияние на бизнес. Но если бизнес может жить с несколькими минутами простоя, то активный/ пассивный кластер может быть гораздо более экономически эффективным (менее затратным по деньгам). Тем не менее, это потребует от вас пойти на консультативные обсуждения с владельцами приложений и выяснить, какое влияние на бизнес окажут несколько минут простоя.

Что касается RPO, то всегда был консенсус, что синхронное зеркалирование данных (или репликация) некоторого вида покрывает все ваши потребности. На самом деле EMC была самой первой, кто предложил синхронное зеркалирование устройств хранения данных с помощью продукта EMC SRDF, примерно в 1995 году. На уровне устройств хранения данных это гарантирует "нулевые потери данных", потому что каждая операция записи ввода/вывода в основную систему хранения данных (источник) будет подтверждена только тогда, когда эти данные также доставлены и подтверждены резервной системой (цель). Пока канал передачи данных функционирует, обе системы - исходная и целевая всегда на 100% синхронизированы, поэтому любая транзакция, записанная основным приложением, гарантированно также будет записана и на целевом (D/R) сайте. В случае (физической) катастрофы база данных будет прервана (крах) и должна быть перезапущена на резервном сайте, используя зеркальный набор данных. Для данных, не являющихся базами данных, например, файловые системы (содержащие плоские файлы) – они также должны быть смонтированы на резервном сайте - но все данные будут представлены именно так, как это было прямо перед катастрофой.

До сих пор - это в теории. Давайте посмотрим, как это в реальности и как Закон Мерфи портит наш идеальный мир.

Целостность, Коммитмент & Откат

Прежде всего, реляционные базы данных (RDBMS, основанные на принципах ACID- Atomicity, Consistency, Isolation, Durability) используют концепцию применить и подтвердить (а иногда и откат) для транзакций. Так приложение может создать или обновить запись транзакции, но не подтверждать (commit) транзакцию некоторое время. Если база данных неожиданно прерывается (нормально или ненормально), прежде чем приложение подтвердило транзакцию, то в целях сохранения целостности базе данных придется "откатить" эту транзакцию к старому состоянию. Это означает, что на уровне базы данных нулевая потеря данных справедлива только для подтвержденных транзакций. Все неподтвержденные транзакции будут потеряны (из-за отката). Эта концепция имеет серьезные последствия для приложений. Если вы хотите реальные нулевые потери данных из конца в конец для вашего приложения баз данных, это означает, что код приложения должен быть написан таким образом, чтобы каждая транзакция, которая не должна быть потеряна, должна быть подтверждена немедленно.

Если приложение нарушает этот закон (из-за оптимизации производительности или, может быть, из-за лени/неосведомленности разработчика), то нулевая потеря данных не гарантируется на 100%.

Таким образом, в теории, с идеально написанным кодом приложений, это не должно быть проблемой. К сожалению, я не встречал такое идеальное приложение нигде за все время моей ИТ-карьеры.

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

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

Нулевая потеря данных в файловых системах

Теперь давайте поговорим о еще большем мифе: файловые системы. В старые времена, файловые системы необходимо было сканировать на проблемы целостности после аварии (помните Windows CHKDSK, CHKNTFS, UNIX fsck и "потерянные+найденные" и эти проверки могли идти часами и часами после сбоя?). Чтобы преодолеть это, многие современные файловые системы имеют средства ведения журналов, которые ведут себя очень похоже на средства ведения журналов баз данных. Они обеспечивают, что при изменении метаданных файловой системы, это изменение записывается в системный журнал файла, так что если файловая система должна быть восстановлена после аварии, то не нужно будет сканировать весь набор данных. Вместо этого, он быстро вновь применит все изменения из журнала и в течение нескольких секунд вы снова в работе. Так что, может показаться журналированные файловые системы предотвращают потерю данных. Но реальность сильно отличается ...

Рассмотрим файловый сервер, используемый для сохранения больших документов Office. Вы как конечный пользователь открываете большой (т.е. 10 МБайт) документ PowerPoint и начинаете редактирование. После этого, когда вы нажимаете «Сохранить», чтобы подтвердить изменения в файл-сервере и его файловой системе. Приложение PowerPoint теперь начинает перезаписывать полный документ, но на полпути в 5 Мб случается авария/катастрофа и срабатывает переключение на резервный ресурс. Резервный сервер монтирует зеркальную копию файловой системы, только чтобы обнаружить, что она не была чисто размонтирована и воспроизводит записи журнала, чтобы вновь сделать файловую систему целостностной. Он находит новый размер PowerPoint файла, времена изменений, другие мета-данные и повторно применяет их на восстановленную файловую систему. Но 10 МБ файл в настоящее время содержит только 5 Мегабайт наполовину сохраненного приложением PowerPoint и еще 5 мегабайт старого файла, прежде чем он был перезаписан. Как вы думаете, что произойдет если вы попытаетесь открыть эту PowerPoint презентацию снова?

В попытке обойти эту проблему, некоторые файловые системы предлагают "данные в журнале" опции для монтирования. Это означает, что не только метаданные (время доступа / изменения, размер файла, владельца / группу и т.д.), но и сами данные записываются в журнале перед записью в реальный файл. Но это не предохраняет файлы от ситуации, когда они только наполовину записаны (если только журнал не сбрасывается в реальный файл сразу после закрытия приложением обработки файла). Накладные расходы (влияние на производительность) этой опции монтирования огромны и вряд ли кто использует его. Чтобы добавить к путанице; некоторые действительно современные файловые системы, кажется, решили эту проблему, потому что они всегда пишут в журнал (как SUN ZFS), но вы все еще рискуете при частично записанных файлах. Не попадите в эту (маркетинговую) ловушку.

Местное или Удаленное восстановление

Теперь, чтобы прояснить некоторый другой миф: Коренная причина этих проблем с повреждением данных / потерей транзакций вызваны дизайном приложения или системы. Если система спроектирована из конца в конец так, чтобы иметь возможность выжить в случае сбоев электропитания без потери данных, то тогда инструменты репликации EMC (SRDF, Mirrorview, RecoverPoint и т.п.) также могут обеспечить нулевые потери данных, теперь и на удаленном расстоянии. Иногда я слышу утверждения, что даже с зеркалированием от EMC Вы можете не получить целостность данных после сбоя и переключения на резервный. Но если это так, то то-же самое верно и для выхода из строя сервера и сбоев питания, и первопричина проблемы находится в стеке приложений, а не в методе репликации. Если ваше приложение может пережить падение сервера без повреждения данных, тогда не имеет значения, восстанавливаетесь ли вы локально или на удаленной D/R площадке (учитывая, что вы используете технологии обеспечения целостности для репликации).

Таким образом, мы пришли к выводу, что реальная нулевая потеря данных (в основном) миф – только если ваш стек приложений не является "с нулевой потерей данных совместимым" (у меня нет лучшего термина для этого) из конца в конец, что случается очень редко.

Катастрофы в теории и в реальности

Если вы читаете официальные документы или маркетинговые материалы по D/R продуктам, вы часто будете видеть преимущества этой технологии, предполагая какую-то одну огромную катастрофу. Классическая – гигантский аэробус врезается в ваш центр обработки данных. Взрыв газа. Массовое отключение электропитания. Во всех этих случаях, часто делается предположение, что вы переходите от полнофункционального центра обработки данных к полностью разрушенному в прах в течение одной микросекунды. Реальность же сильно отличается. В EMC мы называем эти реальные бедствия "Катящиеся Катастрофы". Это означает: проблема сначала возникает небольшая, а затем становится все более и более серьезной в течение определенного периода времени (минуты или несколько часов). Чтобы понять мою точку зрения, рассмотрим, например, пожар в центре обработки данных, который начинается с небольшого возгорания в углу. Огонь начинает расти все больше и выжигает некоторые из каналов глобальной сети, которые используются для D/R зеркалирования в другом центре данных. Репликация приостановлена, но, как правило, политика установлена такой, что производственная система позволяет продолжать обработку данных. Через пять минут огонь достигает серверов и приложения падают (я не пойду настолько далеко, рассматривая, что сервер, который работает перегретым, может привести к повреждению данных, прежде чем наконец произойдет его полный отказ - из-за перегретых процессоров, оперативной памяти, материнских плат, адаптеров Ввода/Вывода или оплавленных кабелей). Итак, несмотря на ваше дорогое зеркалирование с нулевой потерей данных, теперь у вас есть основной центр обработки данных с более поздними данными, чем (целостная) копия на вашем D/R сайте. Теперь вы должны переключиться на резервный центр и смириться с несколькими минутами (или более) потери транзакций... (обратите внимание, что в EMC у нас есть некоторые инновационные решения чтобы справиться с этой проблемой - но это уже выходит за рамки этого поста).

Между прочим, если вы в состоянии потушить пожар и отремонтировать серверы (при условии, что устройства хранения данных находятся по-прежнему там), то как вы собираетесь переключаться обратно? У вас сейчас есть записанные обновления данных независимо друг от друга на обоих сайтах – а большинство инструментов репликации будет просто не в состоянии выполнить инкрементальную ресинхронизацию - или что хуже, вызовут скрытые повреждения данных при переключении назад ...

Синхронный или Асинхронный

Так почему же мы до сих пор предпочитаем синхронное зеркалирование для приложений? Особенно когда синхронные операции записи вызывают снижение производительности (то есть операция записи должна быть направлена на удаленную систему D/R и подтверждение от нее должно вернуться обратно прежде, чем мы сможем приступить к следующей транзакции)?

Мое мнение, что это в основном вопрос наследия. EMC была первой, предложившей синхронное зеркалирование, и так он стал де-факто стандартом для многих организаций. Другие производители догнали EMC и частично обогнали EMC, предлагая асинхронную репликацию. С асинхронной репликацией вы не ждете подтверждения и просто продолжаете работу со следующей транзакцией, так что теоретически не существует больше никакого влияния на производительность. Проблема была в том, что порядок, в котором вы обрабатываете операции записи Ввода/Вывода, имеет критическое значение для обеспечения целостности данных. Вкратце: если вы измените (рандомизируете) порядок операций записи, то ваши данные на D/R сайте полностью бесполезны и не годятся для восстановления бизнеса в случае аварии. Для того чтобы поддерживать согласованность транзакций, конкурирующие производители должны были реализовать в своих решениях либо соблюдение очередности операций записи Ввода/Вывода - в результате чего процесс репликации становится однопоточным, вызывая огромные узкие места - либо маркировки каждой отдельной операции Ввода/Вывода с помощью временной метки или идентификатора последовательности - вызывая массивную дополнительную нагрузку на каналы репликации. Оба метода оказалась слишком непрактичными для высокопроизводительных сред.
Некоторые реализации асинхронной репликации вообще не гарантировали порядок операций Ввода/Вывода, и они были в основном бесполезны для правильной стратегии D/R. Существование таких вот методов, вероятно, и вызвало миф, что Асинхронная репликация не годится вообще.

Вот почему ЕМС ждала долгое время, прежде чем предложить свой вариант асинхронного зеркалирования (SRDF/A), и мы наконец сделали возможным достижение целостности при асинхронном зеркалировании без влияния на производительность, в основном с помощью расположенных в оперативной памяти буферов применить /подтвердить и своего рода контрольных точек (я пропущу детали, но просто примите к сведению, что это работает как было запроектировано).

Значение RPO, которое мы можем достичь при асинхронной репликации, в два раза превышает время цикла для контрольных точек. Так что, если вы установите время цикла в 1 минуту, то ваш RPO будет 2 минуты (в худшем случае). Это означает, что после переключения при аварии вы потеряете 2 минуты последних транзакций. Все данные будут по-прежнему 100% действительны и целостные. Значение RTO (время переключения/ восстановления) не сильно изменится. Итак, асинхронное зеркалирование не так уж плохо для многих приложений (учитывая, что всего лишь несколько лет назад мы опирались на перенос носителей и восстановление с магнитных лент – что обычно вело к RPO равному 24 часа или более - если восстановиться удавалось успешно, что было не всегда).

Бизнес-требования

Итак, если Асинхронная репликация (EMC) гарантирует согласованность транзакций, и только вызывает рост значения RPO от нуля (теоретически) до нескольких минут, и еще снижает дополнительную нагрузку на производительность приложения до нуля, то почему же большинство организаций по-прежнему предпочитает использовать 100% синхронную репликацию?

ИМХО, для более 95% всех бизнес-приложений асинхронное зеркалирование более чем достаточно. Исключение составляют те среды, где секундная стоимость транзакций представляет большую ценность для бизнеса - это в основном относится к финансовому процессингу, при котором одна транзакция может представлять миллионы долларов (или любую другую валюту), но я также могу думать и о нескольких нефинансовой приложениях, где ценность отдельных транзакций очень высока.

Вернемся опять к людям бизнеса, которые снова просят мифические нулевые потери данных. Спросите их, какое влияние на бизнес будет, если потерять данные последних 5 минут. Могут ли они выразить это в стоимости денег? Хотя это трудно, вы можете по крайней мере попытаться вычислить приблизительное значение на основе некоторых предположений.

Теперь, если стоимость синхронной репликации (влияние на производительность, более дорогие каналы связи для репликации, требуемые дополнительные приложения/ настройки системы и т.д.) выше, чем стоимость тех немногих минут транзакций, то моя рекомендация идти с асинхронной репликацией (которая будет в результате, как сказано, в более 95% всех случаев).

Это не легкий путь, потому что это потребует от вас пойти на консультативные дискуссии с людьми бизнеса в вашей организации. Но награда есть: это экономия затрат и улучшение производительности (эй, вот почему я начал этот блог).

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

Заключительный миф: Катастрофы очень маловероятны

Кстати, фото в начале этого поста с Costa Concordia, и я плавал в круизе на этом судне с женой за 6 месяцев до его катастрофы. Я до сих пор помню, как мы однажды вечером, медленно гуляя по боковой палубе в середине Средиземного моря, глядя на спасательные шлюпки над нашими головами, и я сказал ей, что они, вероятно, никогда не используют их, потому что современные круизные суда очень безопасны ...

Обновление: Я получил сообщение от одного из моих клиентов (спасибо Саймон!), что я представил дело так, будто SRDF / Asynchronous является новой функцией EMC. Для того чтобы избежать путаницы: Асинхронный режим (с обеспечением целостности набора данных) был предложен где-то в 2001/2002 годах (проверьте здесь), так что он был уже в течение некоторого времени.