В теории высокая важность постоянной готовности данных предприятия для делового успеха бесспорна. Однако на практике, как и прежде, остаются существенные пробелы в стратегиях обеспечения безопасности и готовности данных. Обычные системы резервного копирования — даже работающие в режиме, близком к реальному времени, — оказываются не пригодны, когда некоторым деловым процессам требуется постоянная готовность критически важных для предприятия данных. Они не терпимы к каким бы то ни было отказам, авариям или саботажу. Даже самые простые профилактические работы могут отрицательно сказаться на продуктивности деловых процессов, если необходимые данные размещаются на носителях, которые в настоящий момент отключены для проведения обслуживания, обновления или прочих административных действий.
В таких условиях, казалось бы, хранение данных в двух или более вариантах на дисковых системах хранения, то есть тиражирование, становится наилучшим выбором. На первый взгляд, ничего сложного, но на самом деле, это не так.
ИГРА «В СТЕНКУ»
Для лучшего понимания процесс тиражирования необходимо рассмотреть с точки зрения непрерывности бизнеса. Обычно такой сценарий выглядит следующим образом: локальный сервер служит в качестве первичного источника данных для доступа с целью чтения или записи, а вторичный сервер работает как удаленный и резервный накопитель для всех данных, поступающих с первичного сервера. Как правило, механизмы тиражирования оцениваются на основании двух важных параметров. Во-первых, целевая точка восстановления (Recovery Point Objective, RPO). Это момент, когда первичный сервер отказывает и больше не передает данные на вторичный сервер. Во-вторых, целевое время восстановления (Recovery Time Objective, RTO) — временной промежуток между отказом первичного сервера и включением в работу вторичного.
Соединение между обоими серверами может быть организовано разными методами, причем на выбор правильного типа соединения влияют протяженность перекрываемых расстояний и величина издержек. Последние не стоит недооценивать. При расчете предельных издержек они часто оказываются больше, чем затраты на процессы ввода/вывода между первичным и производственным сервером, к примеру, сервером приложений или электронной почты.
ЗАМЕНА
Какие же действия предпринимаются, если происходит какой-либо сбой? Допустим, первичный сервер — неважно, по каким причинам, — выходит из строя. Тогда немедленно должен подключиться вторичный и взять на себя обеспечение непрерывности процессов. Процесс доступа (вручную) к соответствую-щим томам вторичного сервера и перезапуск связанных с этим приложений называется преодолением отказа (failover). Теперь все сетевые клиенты рассматривают в качестве адресата своих потоков ввода/вывода вторичный сервер. Впоследствии при подсчете затрат выявляются дополнительные расходы на соединение. Однако они гораздо меньше, чем ущерб, вызванный параличом деловых процессов.
При восстановлении работоспособности первичного сервера актуальные данные переписываются со вторичного, и первичный вновь берет на себя роль ведущего. В принципе, этот процесс равносилен еще одному преодолению отказа, то есть связан с прерыванием и последующим увеличением объема передаваемых данных. В таком случае говорят о возобновлении после отказа (failback).
Как же ведут себя в подобном сценарии два базовых параметра — RPO и RTO? Начиная с момента отказа первичного сервера, данные больше не тиражируются на вторичный. Неизбежная потеря данных может быть незначительной, особенно при наличии системы контроля исходных текстов программ (Source Code Control), но может иметь и серьезные последствия: в банковской отрасли или в области авиаперелетов потерянные за несколько секунд данные электронного бронирования могут привести к неустранимому ущербу. В этом отношении показатели RPO можно рассматривать как максимально допустимый объем потерянных данных. В случае важных приложений он, соответственно, должен быть близок к нулю. Иными словами, операция ввода/вывода на первичном севере и тиражирование на вторичный должны осуществляться одновременно. Лишь тогда удастся обеспечить соответствие обоих массивов данных в любой момент времени.
RTO, напротив, представляет собой момент времени, когда вторичный сервер реально берет на себя функции первичного. Связанный
с этим временной промежуток хронологически примыкает к RPO и ведет к дополнительным потерям данных. Оптимальное значение RPO также равно нулю. Таким образом, главное, что необходимо выяснить, — достижимы ли нулевые значения, и если да, то сколько это будет стоить?
УПРАВЛЯЕМАЯ ЗАЩИТА
При выборе подходящей концепции тиражирования необходимо сравнить между собой RTO, RPO и возникающие издержки. С технической точки зрения можно тиражировать данные без временной задержки, то есть сократить значения RTO и RPO до нуля. Но эта форма безопасности и высокой готовности имеет свою цену.
При так называемой активно-активной кластеризации и зеркалировании первичный и вторичный серверы находятся в активном состоянии одновременно, координируют свои операции между собой и сохраняют полную функциональность и при работе поодиночке. В случае отказа одного сервера второй продолжает выполнять задачи ввода/вывода до тех пор, пока ошибка не будет устранена.
С технической точки зрения и из соображений высокой готовности деловых данных и непрерывности бизнес-процессов, это оптимальное решение. Для поддержания связи между приложениями и кластером из первичного и вторичного серверов, а также взаимодействия между самими серверами необходимы сверхбыстрые широкополосные соединения с высокой скоростью передачи данных. Если расстояния между филиалами велики, такие соединения потребуют огромных расходов — шести-, а то и семизначных контрактов в евро.
Далее с функциональной точки зрения следует синхронное тиражирование в активно-пассивном режиме. Здесь процессы ввода/вывода выполняются исключительно первичным сервером. Любое изменение массива данных, то есть любая команда на запись информации, перед выполнением согласуется с вторичным сервером. Лишь когда изменение происходит и там, оно подтверждается. Благодаря такому согласованию массивы данных обоих серверов в любой момент времени идентичны, а RPO достигает идеального нулевого значения. Но поскольку приложения видят только первичный сервер, в случае отказа необходимо передать управление и выполнить восстановление, в результате значение RTO может возрасти до нескольких часов. Чтобы его сократить, системы Stortrends, например, предлагают функциональность многомаршрутного ввода/вывода (Multi Path I/O, MPIO), когда в момент отказа система осуществляет автоматическое переключение с первичного сервера на вторичный без вмешательства администратора.
Синхронное тиражирование требует наличия высокопроизводительного соединения между первичным и вторичным серверами, с соответствующими затратами. Впрочем, благодаря тому, что приложения обращаются только к первичному серверу, платить за их соединение с вторичным сервером не приходится, что позволяет несколько сократить издержки.
ТАКТИКА ЗАДЕРЖКИ
Говоря об экономической стороне дела, следует обратить внимание на то, что соединения между первичным и вторичным серверами довольно дороги. Для синхронной передачи данных между первичным и вторичным серверами необходима очень широкая полоса пропускания и высокая скорость передачи данных. Поневоле приходится задумываться о возможности промежуточного сохранения, сжатия и оптимизации данных для передачи. Благодаря этому можно было бы свести к минимуму требования к соединениям и связанные с ними затраты.
Таким образом мы переходим к асинхронному тиражированию. В этом случае данные передаются с первичного сервера на вторичный с задержкой. Данные ввода/вывода можно объединять в группы и передавать их параллельно, кроме того, отпадает необходимость в двукратном доступе для записи данных по одному и тому же логическому адресу блока (Logical Block Addressing, LBA). Это сокращает не только издержки и затраты на маршруты передачи, но снижает время задержки первичного сервера и увеличивает его производительность ввода/вывода. Однако розы без шипов не бывает. При использовании этого метода сократить RPO до нуля или приблизить к нулевому значению невозможно. Впрочем, для многих приложений его значение оказывается пренебрежимо малым.
Несколько дальше идет тиражирование с применением моментальных снимков, когда через равные промежутки времени делаются моментальные копии массива данных. Снимок представляет собой сумму всех изменений по сравнению с предыдущим снимком и дает возможность избежать повторного доступа для записи в период между созданием снимков. Поскольку как старый (вторичный), так и новый (первичный) массивы данных из-вестны, передаваемые данные можно сжимать более эффективно. В этой концепции тиражирования RTO может быть ниже, чем при синхронном и асинхронном методе, однако сократить его менее, чем до одной минуты, удается редко.
Большое значение имеет максимально возможное количество создаваемых снимков. Обычно оно находится в диапазоне между восемью и 64. Stortrends поддерживает 254 снимка, что позволяет увеличить интервал времени или «детализированность сохранения», к примеру, создавать снимки в течение финансового года каждый день и сохранять эти данные.
ОТКАЗ КАНАЛОВ
Отказы каналов, то есть кратковременные прерывания сетевых соединений, могут вызывать системные сбои, но слишком часто игнорируются в качестве их причин. Важнейшими являются два вопроса: во-первых, насколько велика терпимость системы хранения к длительности отказа канала, и во-вторых, как система хранения поведет себя при отказе канала, когда его длительность превысит допустимое значение? Чем выше терпимость, тем меньше вероятность отказа системы со всеми его рисками и дополнительными затратами на преодоление отказа и восстановление после него. Многие системы принимают меры уже при длительности отказа канала в 20 мс. При значении терпимости в 100 мс количество системных отказов значительно снижается.
Но и на те случаи, когда временной лимит внутренней обработки отказа соединения превышается, имеются механизмы для упрощения ресинхронизации. Для синхронного тиражирования предлагается так называемая табуляция. При отказе соединения создается таблица, куда помещается список тех секторов, которые получали потоки ввода/вывода. Благодаря алгоритму нового типа разборных таблиц ресинхронизации (Collapsible Resync Tables, CRT) разрешение можно выбрать таким образом (64 Кбайт — уровень сектора), что передаваться будут только абсолютно необходимые данные. Это сокращает их объем, уменьшает необходимую пропускную способность для передачи и соответствующие затраты, а также потребность во времени для синхронизации обоих серверов хранения.
При асинхронном тиражировании отказы могут быть устранены, если в процессе ресинхронизации переключить систему в синхронный режим, а потом снова вернуться в асинхронный — если это только возможно!
СВИСТОК К ОКОНЧАНИЮ
Общую рекомендацию по разным механизмам тиражирования дать невозможно: любые рекомендации основываются на индивидуальных требованиях, сетевых сценариях и учете затрат предприятия. Важно, чтобы система хранения данных была реализована с учетом всех важнейших механизмов тиражирования и быстро масштабировалась в соответствии с растущими или меняющимися требованиями. С точки зрения высокой готовности следует указать на часто возникающее недоразумение: система хранения никогда не может обеспечивать высокую готовность сама по себе — она всегда является частью всеобъемлющей концепции обеспечения высокой готовности.
Винфрид Прель — коммерческий директор American Megatrends International (AMI).
© AWi Verlag