У меня есть долгосрочная цель создать сайт аварийного восстановления где-нибудь в одном месте, и часть этого плана включает репликацию некоторых томов моей EqualLogic SAN. Мне трудно это делать, потому что я не знаю, верен ли мой метод.
Этот пост может быть немного длинным для полноты картины.
Представитель Dell сказал мне, что способ (возможно, не самый лучший?) Для оценки дельт в томе - это измерить резервное пространство для моментальных снимков, используемое в течение определенного периода времени в соответствии с расписанием регулярных моментальных снимков.
Мой первый эксперимент с этим заключался в создании расписания на 15 минут между моментальными снимками с резервом моментальных снимков в 500 ГБ. Я оставил это работать на ночь и до COB на следующий день. Я не помню, сколько снимков можно было хранить в 500 ГБ, но в итоге я получил в среднем ~ 15 ГБ на снимок.
$average_snapshot_delta = $snapshot_reserve_used / $number_of_snapshots
Затем я изменил интервал между снимками на 60 минут, что по прошествии полных 24 часов означает в общей сложности 13 снимков на 500 ГБ. Это оставляет мне ~ 37 ГБ в час (или ~ 9 ГБ за 15 минут).
Для меня эти числа астрономические. С моей пропускной способностью я могу делать чуть более 1 ГБ / час при 100% использовании. Так ли дорого обходится блочная репликация или я что-то делаю неправильно?
Ваши цифры сводятся к 10,24 МБ / с, что кажется немного завышенным для чистой записи. Но тогда я не знаю ваших рабочих нагрузок.
Однако у вас есть более серьезная проблема. Первоначальная репликация будет реплицировать 1 ТБ данных через соломинку 3 МБ / с.
1TB = 1024GB = 1,048,576 MB
2.8 MB/s replication speed
~4.33 days
В течение этого времени он будет ставить ваши сетевые изменения в очередь до завершения начальной синхронизации. И если вам когда-либо понадобится извлечь данные из удаленного массива, пройдет 4,33 дня, пока вы полностью не заработаете (если только у вас нет внеполосного метода передачи данных, например, FedEx Overnight Shipping или грузовая машина).
Что касается разницы в чистом изменении между вашими 15-минутными снимками и 60-минутными снимками, я считаю, что 60-минутный снимок извлекает выгоду из большого количества операций записи-комбинирования. Или, другими словами, все эти записи в журналы файловой системы объединяются в более длинный моментальный снимок так, как их не так много в 15-минутных снимках.
Именно здесь режим синхронизации действительно проявляет себя. Канал со скоростью 3 МБ / с крайне недостаточен для синхронной репликации. Пакетная асинхронная репликация получит некоторые преимущества комбинирования записи и, следовательно, более низкую общую передачу за счет потери некоторых данных в случае аварии. К сожалению, я недостаточно хорошо разбираюсь в Equilogic, чтобы знать, на что он способен.
На мой взгляд, это самый большой обман против Equallogic. Репликация основана на моментальных снимках, и их технология моментальных снимков невероятно неэффективна.
Мы запускаем около 25 массивов в нашей среде, и моя цель на 2-3 года - заменить их все на netapp. Основываясь на том, что мы видим в наших файловых серверах netapp cif и при тестировании nfs, пропускная способность репликации и пространство для моментальных снимков будут уменьшены на 80%. добавьте к функциям дедупликации netapp, и это будет намного эффективнее.
Обязательно поместите файлы подкачки Windows и файлы подкачки VMware на нереплицируемый том.
Также - если вы можете себе это позволить, посмотрите на добавление некоторых оптимизаторов русла реки. Они уменьшат объем данных в вашем WAN для ответа примерно на 60%. Это спасло нас, и у нас есть минимум ds3 wan-соединений до oc-3.
Вы также не упомянули, что такое задержка. Это важный компонент в вычислениях репликации.
Если файлы подкачки ваших виртуальных машин не хранятся в отдельном хранилище данных, попробуйте переместить их в одно хранилище, а затем повторно измерить скорость изменения данных (отток данных). Это обязательно поможет. Не копируйте больше, чем нужно.
Поддерживает ли EQL непрерывную асинхронную репликацию или управляется расписанием моментальных снимков? Можете ли вы использовать все 3Мб 24/7?
Я также поддерживаю предложение синхронизировать массивы перед размещением одного на удаленном сайте.
Чтобы сосредоточиться на наиболее актуальной информации, я бы предложил определить цель для точки восстановления и времени восстановления. Их условно называют «RPO» и «RTO». Репликация диска должна уменьшить их количество, сохраняя на другом сайте устойчивую к сбоям копию данных, которая никогда не старше нескольких минут. Как только у вас есть эти числа, вы можете определить такие вещи, как, например, как часто у вас должна быть согласованная с сбоями копия .
3 Мбит / с, вероятно, не сократят скорость, если вы не используете ускорение WAN (например, Riverbed, упомянутый одним из других респондентов). Ускорение WAN работает, сохраняя кеш на диске по обе стороны от ссылки, где они хранят все самые последние данные, которые вы отправили, и если вы когда-либо отправляете дублирующийся блок, он отправляет ссылку вместо данных.
Тем не менее, если предположить, что ваше хранилище использует тот же механизм для создания снимков, что и для репликации снимков, то наиболее точным показателем изменений действительно является резерв снимков. Однако вам нужно будет держать один снимок и его резерв изолированными на время периода измерения. Предполагая, что EqualLogic использует копирование при записи моментальных снимков, сравнение данных из резерва нескольких снимков, сделанных в течение дня, может на самом деле создать впечатление, что ваши данные меняются больше, чем есть на самом деле.
Что касается самих данных, я согласен с ответами, в которых предлагается не копировать файлы подкачки. Файлы подкачки могут занимать много места на диске и постоянно меняются, что может вызвать большой трафик репликации. Я не знаю, поддерживает ли VMWare репликацию среды без них ... Я предполагаю, что виртуальные машины в хранилище данных виртуальных машин, реплицированные без файлов подкачки, будут устойчивыми к сбоям, однако я не могу это подтвердить.
В настоящее время я работаю над чем-то похожим, но с Solaris 11 и zfs в качестве нашего san backend. Из-за пропускной способности я решил отделить большинство компонентов. Мы перешли на Exchange 2010, чтобы мы могли настроить наш сайт dr с идентичной копией. То, что я обнаружил, создание снимков на уровне san было бы нелепо для этих данных из-за проблем с пропускной способностью, которые вы наблюдаете. Мы решили, что будет дешевле и эффективнее настроить даг и тиражировать внутри самой биржи. То же самое мы сделали и с нашими серверами mysql. То, что мы клонируем сейчас, - это системы с меньшими отклонениями между снимками. Я смог выполнить первоначальную синхронизацию в офисе и перевезти его в конечный пункт назначения.
Размер блока составляет 16 млн. Для моментального снимка и репликации в Equallogic SAN. Вот почему у вас есть астрономические числа. Это невозможно изменить. Решением для нас, отвечающим нашему SLA по RTO / RPO, стала установка Riverbed WAN Optimization Appliance между двумя сайтами.