До сих пор развивались и использовались два подхода к осуществлению резервного копирования. Первый подход, локальные резервные копии на магнитных лентах, требует установки постоянно доступных ленточных библиотек (Tapes Library) везде, где имеются серверы. Скоростная локальная сеть позволяет быстро выполнять резервное копирование и аварийное восстановление. Второй подход, централизованное резервное копирование, предусматривает внедрение мощных ленточных библиотек, обладающих очень большой емкостью хранения, в центральных офисах или ЦОД, где и осуществляется централизованное сохранение данных с серверов, распределенных по всему предприятию.
Вслед за повышением емкости жестких дисков и удешевлением носителей информации в сфере технологий резервного копирования намечается еще одна тенденция: резервное копирование с диска на диск (Disk-to-Disk-Backup) в виде вторичных систем хранения и виртуальных ленточных библиотек (Virtual Tape Library, VTL). Технологии создания «моментальных снимков» (Snapshot) в современных системах хранения в сочетании, к примеру, с реляционными базами данных позволяют еще больше сократить время, необходимое для резервного копирования и аварийного восстановления. Технологии резервного копирования/аварийного восстановления подразделяются на следующие категории: полное (Full Backup), инкрементальное (Incremental Backup), дифференцированное (Differential), синтетическое полное (Synthetic Full) резервное копирование, а также непрерывная защита данных (Continuous Data Protection, CDP).
Для синхронизации массивов данных в распределенных ЦОД применяются синхронные и асинхронные технологии тиражирования. В первом случае данные параллельно записываются на исходную и удаленную системы хранения. Запрос записи на исходной системе подтверждается лишь по завершении процесса записи на целевой системе. Такая схема встречается в сценариях тиражирования в высокопроизводительных сетях хранения (Storage Area Network, SAN). Как правило, там применяются очень быстрые соединения для передачи данных с низким уровнем задержки. Во втором случае процессы записи на исходной и удаленной системах могут осуществляться независимо друг от друга. Среди прочих различают методы на базе снимков (Snapshot), уровне блоков и байтов. В среде локальных и городских сетей (Metropolitan Area Network, MAN) эти методы, как правило, функционируют очень хорошо. Проблемы появляются, когда увеличивается задержка на линиях передачи, а в распоряжении пользователя имеется только глобальная сеть с гораздо более узкой полосой пропускания по сравнению с локальной/городской сетью.
Для экономии пропускной способности и места на носителях информации на линиях передачи все активнее начинают использоваться технологии дедупликации данных. При этом в потоке пакетов выявляются и устраняются избыточные фрагменты. Данные могут рассматриваться на уровне блоков, файлов, пакетов или потоков. Дедупликация производится отправителем, при передаче по сети или при записи на носитель резервных данных. Уже сохраненные данные можно дедуплицировать с помощью постобработки. Такие разнообразные подходы приводят к разной степени эффективности процесса дедупликации. В идеальных условиях сетевые механизмы могут снизить изначальный объем данных до одной десятой. Объем первично передаваемой информации можно сократить благодаря применению разнообразных методов сжатия без потерь, однако такой подход менее эффективен, чем дедупликация уже известных фрагментов.
В результате все усиливающейся централизации служб ИТ и изменения законодательных требований в отношении хранения данных (Compliance) преимущества централизованного резервного копирования становятся очевидны, однако перед менеджерами ИТ встает целый ряд вопросов, связанных с защитой данных. Каково соотношение требований к пропускной способности соединений и затрат на потенциально необходимую дополнительную емкость? На чем делается основной акцент: на моменте восстановления (Recovery Point) или времени восстановления (Recovery Time)? Проедоставляются ли для тиражирования ЦОД выделенные линии, или пропускную способность придется делить с другими важными корпоративными приложениями? Каков уровень задержек на высокоскоростных соединениях между ЦОД и резервным ЦОД? Теряются ли пакеты при передаче? Возможна ли полная загрузка линии?
К примеру, если для данных объемом 120 Гбайт на копирование предоставляется 8 часов, то, на первый взгляд, достаточно и линии E3 (34 Мбит/с). При задержке в 100 мс емкость такой линии (Bandwidth Delay Product, BDP) составляет 425 Кбайт (для большей наглядности 1 Кбайт здесь принимается равным 1000 байт). Если для передачи используется окно перегрузки (Congestion Window Size) протокола TCP размером 64 Кбайт, то в идеальной ситуации без масштабирования окна (Window Scaling) для передачи всех данных потребуется 1875 млн циклических обращений (Roundtrips; 120 Гбайт : 64 Кбайт). При круговой задержке (Round Trip Time, RTT), равной 100 мс, это займет более двух дней (без учета TCP Slow Start, а также потерь и повторной передачи пакетов), что существенно превышает допустимый промежуток времени для резервного копирования. В критичес-кой ситуации восстановление старых данных заняло бы больше двух дней.
В этой связи имеет смысл задуматься о том, как уместить процесс резервного копирования в заданные временные рамки. Конечно, с этой целью можно увеличить пропускную способность или принять меры для лучшей загрузки имеющегося соединения. В случае вышеуказанной задержки и наличия времени, достаточного для резервного копирования (или процесса восстановления), допустимо 8х60х60/0,1 — 288 тыс. циклических обращений, что подразумевает использование окна перегрузки размером 417 Кбайт. В этом контексте будет интересно подробнее рассмотреть тему оптимизации и ускорения глобальной сети. Благодаря интегрированию ускорителей глобальной сети можно организовать передаваемые через сеть данные таким образом, чтобы передача укладывалась в заданные временные рамки или занимала еще меньше времени.
ОСОБЕННОСТИ СОЕДИНЕНИЯ ЦОД
При соединении нескольких ЦОД с соответствующими механизмами аварийного восстановления действуют другие условия, нежели при подключении филиалов, когда офисные приложения и средства резервного копирования консолидируются по глобальной сети в рамках смешанной эксплуатации. Это влечет за собой особые требования к схеме и функциям ускорителя глобальной сети (контроллер оптимизации глобальной сети — WAN Optimization Controller, WOC). Как правило, для связи между ЦОД применяются очень быстрые соединения, часто со скоростями свыше 100 Мбит/с. Между обеими сторонами создаются немногочисленные, но зачастую очень длительные сеансы. Нередко передаются огромные массивы данных. Нагрузка может быть распределена произвольно и возникать последовательно. Если в случае относительно медленных соединений глобальной сети речь идет о том, чтобы повысить пропускную способность этих линий с помощью интеллектуальных сетевых методов дедупликации, то в случае так называемых протяженных сетей с высокой пропускной способностью (Long Fat Networks, LFN) — о том, как их максимально загрузить.
Интеллектуальные контроллеры WOC позволяют настроить параметры для достижения эффективной пропускной способности и соблюдения размера окна передачи: в зависимости от сочетания пропускной способности и задержки, а также передаваемых типов данных можно комбинировать механизмы дедупликации на базе жестких дисков и систем хранения, адаптивное сжатие полезных данных и различные высокоскоростные методы TCP. Какие отдельные механизмы или их комбинации следует использовать, определяется в результате предварительного выявления узких мест производительности, возникающих из-за особенностей применяемых технологий: распределение нагрузки на доступные ядра центральных процессоров, интеллектуальное распределение словарных записей для дедупликации данных на уровне дисков и хранения на массовых и энергозависимых системах хранения, оптимизация параметров сжатия и буферов данных на таких передающих компонентах, как контроллеры, маршрутизаторы и т.п.
Высокоскоростные методы TCP часто дополняются «заполнением трубы» (Fill the Pipe). Еще в 1994 г. Вилламизар и Сонг изучали вопросы оптимизации буферов данных на передающих компонентах (исследование «Высокопроизводительный TCP в ANSNET»). Из их результатов, а также из выкладок Вана Якобсона в RFC 1072 и RFC 1323, можно вывести рекомендации для масштабирования: при переходе с интерфейса локальной сети с широкой полосой пропускания и небольшими задержками на интерфейс LFN с низкой (по сравнению с локальной сетью) пропускной способностью и значительными задержками возникает узкое место. Для загрузки линии нужно, к примеру, размер очереди на следующем маршрутизаторе сделать эквивалентным значению BDP.
ВЫСОКОСКОРОСТНОЙ TCP И CWNDS
Целевые установки для высокоскоростного протокола TCP (High-Speed TCP, HS-TCP) идеально подходит для сред DR: высокая пропускная способность соединений при умеренных требованиях к уровню потерь пакетов, быстрое достижение высокой пропускной способности при медленном старте (Slow Start), быстрое (повторное) достижение высокой пропускной способности при восстановлении из состояния множественных тайм-аутов при повторной передаче (Multi-Retransmit-Timeout) или переход (Ramp-up) к большим значениям окна перегрузки (Congestion Window, Cwnd). Никаких дополнительных откликов от маршрутизаторов или получателей данных ждать не нужно.
Кроме того, производительность должна быть эквивалентна стандартному решению в случае возникновения умеренных или высоких перегрузок с потерей пакетов на уровне 1% и выше. Для этого стандартная функция ответа TCP (см. врезку «TCP, окна перегрузок, BDP и LFN») модифицируется и отображается на контрольные параметры перегрузки. Алгоритм предотвращения перегрузок (Congestion Avoidance) определяет подход, при котором каждое соединение HS-TCP управляет своим Cwnd таким образом, как если бы это было соединение из нескольких объединенных соединений TCP, что позволяет расширить окно в соответствии с требованиями среды LFN.
Помимо этого, применяемые технологии позволяют отменить механизмы предотвращения перегрузок и при потере пакетов выполнить повторную передачу с наивысшим приоритетом, Riverbed называет такой подход MX-TCP (см. Рисунок 1).
Томас Беле — старший инженер по продажам в Riverbed.
© AWi Verlag
Рисунок 1. В отличие от стандартного протокола TCP высокоскоростной TCP повышает пропускную способность при соединении различных ЦОД. Специальные механизмы, например, MX-TCP, еще больше увеличивают производительность линий.
TCP, окна перегрузок, BDP и LFN
Целый ряд алгоритмов, реализованный в различных вариантах стека TCP, предназначен для предотвращения проблем на линии, возникающих со стороны отправителя или получателя, к примеру, при переходе с быстрых локальных сетей на медленную глобальную. Для этого отправитель, среди прочего, управляет так называемым окном перегрузок (Congestion Window, Cwnd), размер которого ограничивает количество неподтвержденных пакетов, находящихся на линии. После короткого периода экспоненциального роста (Slow Start) Cwnd растет линейно на 1 MSS/RTT (максимальный размер сегмента за RTT): при каждом успешном циклическом обращении (подтверждение получено) Cwnd увеличивается на одно значение MSS. В случае утраты пакетов в стандартной реализации TCP (TCP Reno Stack) Cwnd уменьшается вдвое.
RCF1323 описывает расширение протокола для быстрых соединений и использует для этого так называемый «результат задержки пропускной способности» (Bandwidth Delay Product, BDP). BDP отражает емкость линии, то есть объем данных, требуемых для ее заполнения: соединение ОС-12 (622 Мбит/с) между двумя площадками с RTT в 60 мс и размером сегмента (со стороны локальной сети) в 1500 байт вмещает теоретически 3110 пакетов. Стеки должны обрабатывать такое количество (неподтвержденных) пакетов, чтобы линия функционировала на пределе своих возможнос-тей. В случае протяженных сетей с высокой пропускной способностью (Long Fat Network, LFM) речь идет о BDP от 100 тыс. бит (RFC 1072). Однако в этой среде возникают проблемы с максимальным размером окна Cwnd, который зачастую не превышает 216 бит (64 Кб). Соотношение размера Cwnd и RTT представляет собой максимальную пропускную способность соединения. В случае с упомянутым соединением ОС-12 это приблизительно 1000 Кбайт (64 Кбайт/0,06 с), что существенно отличается от теоретического максимума для таких соединений.
Полезной здесь, среди прочего, может оказаться описанная в RFC1323 опция масштабирования окон ТСР, допускающая окна размером свыше 216 бит. Однако эта опция не всегда обеспечивается сквозной поддержкой. Еще одна проблема — восстановление пакетов в соответствии с предписанным методом отката (Back-off). Помимо таких мер, как быстрая повторная передача (Fast Retransmit), быстрое восстановление (Fast Recovery) и избирательное подтверждение (Selective Acknowledge; RFC 2018), в RFC 3649 для высокоскоростных соединений предусматривается изменение функции отклика TCP.