about NetApp

Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.

Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.

Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.

Среди прочего, она, например, позволяет оценить время на репликацию в текущих условиях и для имеющегося объема данных, без фактической репликации.

Не секрет, что компания IBM продает под названием IBM N-series системы хранения, являющиеся, произведенными для IBM, знакомыми нам системами NetApp FAS. Отличаются они корпусом (вернее передней лицевой панелью), а также “брендированным” IBM-ом софтом. Ну и, конечно, саппортом, оказываемым IBM, и рядом подобных же отличий в процессе продаж и сопровождении (например для системы IBM N-series можно купить диски поштучно, а не целой полкой, как у NetApp).

Но вот как обстоят дела с софтовой совместимостью, например, можно ли установить в качестве партнера репликации SnapMirror к IBM N-series систему NetApp FAS?

Да, это возможно, SnapMirror и SnapVault совместимы между NetApp FAS и IBM N-series, однако помните, что должны соблюдаться соответствия версий Data ONTAP между этими системами (например, в случае использования Volume SnapMirror, получатель репликации должен иметь версию Data ONTAP равную или новее, чем источник). Что может быть определенной проблемой, так как IBM заметно запаздывает с выпуском новых версий Data ONTAP под N-series.

По умолчанию, TCP-окно Snapmirror равно 1,994,752 байт. В структурах, где SnapMirror используется для репликации данных через WAN, такое значение может заметно замедлять процесс репликации. Важно правильно вычислить верные настройки TCP-окна, и соответствующим образом их установить. Базовая формула такова:

Window Size = Round Trip Delay X Desired Rate

Таким образом, если у вас используется канал 10Mb/s и средний RTD равен 100ms, то window size должен быть 125,000 байт.

Несколько замечаний о этом TCP Window size:

Это теоретически минимальное возможное окно, используемое SnapMirror, и может не быть самым оптимальным. Попробуйте несколько вариантов в районе этой цифры, чтобы выбрать наилучшее.
Установить размер TCP window size можно в файле /etc/snapmirror.conf в параметре wsize.
Это надо установить и на системе-получателе репликации.

Другая возможность, которая должна помочь в тонкой настройке, это установка опции:

options snapmirror.delayed_acks.enable off

Эта установка выключает TCP/IP delayed acknowledgments. В сетях с высоким значением задержки, это может дать выгоду. По умолчанию она включена.

romx: Хочу также обратить внимание, что в речь идет именно о тонкой настройке и оптимизации определенных вариантов конфигурации, так как настройки SnapMirror по умолчаню выбраны для удовлетворительной работы в любых условиях. Если вы не уверены в том, что вы делаете, то лучше оставьте по умолчанию. Помните первое правило профессионала: “Работает - не трогай!” :)

Оригинал тут:
http://rajeev.name/blog/2008/03/18/optimizing-snapmirror-performance/
(будьте внимательны, на хостинге этой страницы сейчас сидит веб-червяк-троян!)