Обзор Synology SA3400: новый NAS корпоративного уровня. Часть II01.10.2019 08:47

Обзор Synology SA3400 | Тестирование Synology SA3400

Первую часть обзора можно увидеть здесь.

SSD накопитель A-Data Ultimate SU650 с приятной скидкой

Для тестов функционала и производительности использовался следующий стенд:

• Материнская плата Supermicro X10DRi-LN4+
• Процессор Intel E5–2630 V4 (2,2 ГГц, 10 ядер)
• 64 ГБ DDR4 RDIMM (4 модуля по 16 ГБ)
• Операционные системы: Windows Server 2016 Statdard, Linux CentOS 7, VMware ESXi 6.7
• Сеть: 2×1GbE Intel i350 в транке, 2×10GbE Intel X550
• Для генерации нагрузки использовался FIO 3.14

Тестируемое устройство:

• Synology SA3400, DSM 6.2.2–24922 Update 1
• 6 дисков Seagate ST14000NM0018 (14 ТБ, 7200 об/мин, 512E)
• 2 SSD Toshiba HK6-R 3840 и 7680 ГБ

Подключение

iSCSI

10-гигабитных коммутаторов с RJ-45 (10GBASE-T) в нашем распоряжении не было, так что для iSCSI использовалось прямое подключение через два порта.

Во всех операционных системах настройка подключения не вызвала никаких проблем. К сожалению, в руководстве пользователя DSM не уделено достаточного внимания iSCSI, поэтому стоит напомнить, что для повышения пропускной способности и надёжности соединения для iSCSI не следует использовать агрегацию портов. Для этих целей предназначен многопутевой ввод-вывод (MPIO, multipath IO), требующий правильной настройки со стороны инициаторов и включение многосессионного доступа со стороны таргета.

Для Windows нужно установить компонент Multipath-IO и активировать его для iSCSI (Add support for iSCSI devices в свойствах MPIO или при помощи соответствующих команд PowerShell), при подключении к сессиям выбрать Enable multi-path, выбрать нужную политику (в данном случае мы используем Round-robin). Для некоторых систем хранения данных требуется установка специального модуля DSM от производителя, в случае Synology используется обычный DSM.

В ESXi подключение iSCSI с корректно работающим многопутевым доступом выглядит нетривиально, но, к счастью, существует подробное руководство Multipathing Configuration for Software iSCSI Using Port Binding. Для iSCSI создаётся отдельный vSwitch, к нему подключаются две портгруппы, в каждой из которых нужно оставить только один активный интерфейс.

Для Linux стандартом являются инициатор Open iSCSI и демон multipathd, который через Device mapper презентует одно блочное устройство из нескольких, соответствующих разным путям доступа. Политика доступа, алгоритм проверки путей и другие настройки в большинстве дистрибутивов хранятся в /etc/multipath.conf

Производительность

Последовательный доступ

Для тестов последовательного доступа запускалась серия из 30 раундов по 60 секунд со следующей нагрузкой:

• 100% чтение, последовательный доступ, размер блока 256 КиБ
• Один поток, глубина очереди 64
• Прямой доступ через libaio: --ioengine=libaio --direct=1

Тестируемое устройство: iSCSI LUN размером 1,2 ТиБ на массиве RAID-6 из шести дисков Seagate ST14000NM0018. LUN предварительно заполнялся случайными данными при помощи FIO. Для того, чтобы исключить влияние RAM-кэша со стороны ОС, результат определялся усреднением последних 10 раундов теста, они запускались со смещением в 200 ГиБ от первых двадцати.

Результаты: 993 МиБ/с при использовании одного соединения (multipath в режиме fail-over) и 1825 МиБ/с при переключении политики в round-robin. Нагрузка на процессор NAS не превышала 3%. Результаты получились вполне ожидаемыми. Ограничивающими факторами были пропускная способность сети, а во втором случае — диски.

В измерении производительности записи необходимости не было — она упирается в диски с учётом используемого массива (в RAID-5/6 без write-back кэша системе редко удаётся писать полными страйпами. Интересна не пропускная способность, а то, что при последовательной записи на массив RAID-6 из 6 жестких дисков нагрузка на процессор NAS колебалась в диапазоне 13–20%. Локальный тест на запись с запуском FIO в консоли самого SA3400 показал нагрузку меньше 3%, так что это вышеупомянутая нагрузка связана с работой iSCSI-таргета. Этот фактор необходимо учитывать при планировании проектов, в которых предполагается высокая нагрузка на запись.

SSD-кэш

Подробно о том, как именно организован SSD-кэш в Synology, было рассказано выше. От теоретических основ перейдём к практике в виде нескольких синтетических тестов. Мы узнаем, как именно влияет наличие SSD-кэша на производительность iSCSI LUN, расположенного на сравнительно медленном массиве RAID-6 из шести жёстких дисков.

Условия тестирования:

• SSD-кэш объёмом 200 ГБ создавался в двух режимах: write-back кэш (чтение+запись) в RAID-1 и write-through кэш (только чтение) в RAID-0
• Тестовая нагрузка состояла из 120 раундов для WB-кэша и 80 для WT-кэша (из-за большей скорости наполнения) продолжительностью 60 секунд плюс 5 секунд прогревочного интервала.
• Нагрузка: размер блока — 4 КиБ, соотношение чтение/запись — 100/0, для WB дополнительно 70/0. 4 потока с глубиной очереди 16.
• Прочие параметры FIO: --ioengine=libaio --direct=1 --randrepeat=0 --norandommap --thread
• Для гарантированного выхода на 100% попадание в кэш размер тестируемой области установлен в 100 ГБ (в два раза меньше размера кэша).

WB-кэш, IOPS:

Видим типичную картину с наполнением кэша. По мере увеличения процента попадания в кэш производительность растёт с нескольких сотен IOPS до 90/56 тысяч. Нагрузка на процессор: 5–6% при 100% чтении, 25–33% при 70/30%.

WB-кэш, задержка:

В случае с 100% нагрузкой на чтение происходит ожидаемое снижение задержек на порядок, но при 70% всё не так просто: в процессе наполнения кэша наблюдается, наоборот, существенный (в 10 раз) рост значений 99,99-перцентиля задержки. Конечно, это синтетический тест, и подобная статистика означает, что всего лишь 0,01% (одна десятитысячная) всех операций ввода-вывода стали завершаться с существенным замедлением. Пригодность SSD-кэширования стоит оценивать на реальных задачах — в случае отсуствия положительного эффекта можно рассмотреть возможность размещения критичных к производительности томов полностью на SSD.

Зачем нужен кэш исключительно на чтение, когда есть возможность кэшировать ещё и запись? Тут может быть несколько причин, главная из которых — кэш на чтение абсолютно безопасен. Аварийное отключение системы или сбой массива с SSD-кэшем не приведут к нарушению целостности данных на основном томе. Во-вторых — для определённых задач, предполагающих практически 100% нагрузку на чтение, WT-кэш может оказаться более выгодным за счёт большего объёма и производительности, так как SSD для него можно объединить в RAID-0.

График IOPS практически идентичен графику с WB-кэшем с поправкой на более высокий лимит производительности (для WT-кэша SSD объединены в RAID-0).

Отслеживание уровня задержек выявляет различие — существенно более стабильное значение задержки. Перцентиль 99,99 при наполнении WT-кэша снижается на целых два порядка вместо одного, как было с WB. Обратная сторона медали — нагрузка на процессор выросла до 45%.

В итоге можно сделать следующие выводы. SSD-кэш в Synology DSM работает в целом предсказуемо и действительно обеспечивает прирост производительности при доступен к горячим данным практически до уровня используемого для кэширования массива из твердотельных накопителей. Целесообразность применения SSD-кэширования, выбор его размера, режима работы должен определяться в ходе тестов с реальной нагрузкой.

RAM-кэш

DSM использует большую часть свободной оперативной памяти для кэширования операций чтения. Как уже упоминалось выше, iSCSI-таргет использует файловый бэкенд и, следовательно, тоже кэшируется. Узнать, как кэширование повлияет на производительность со стороны подключённого через 10GbE iSCSI-инициатора можно при помощи простого теста — серии из 36 раундов (насыщение кэша произошло гораздо быстрее, продолжительность теста была выбрана с запасом) продолжительностью 60 секунд, состоящих из случайного доступа на чтение блоками 4 КиБ. Число потоков — 4, глубина очереди — 16. Раунды отделены 5-секундными прогревочными интервалами. Свободной памяти было более 12 ГиБ, нагрузка была сосредоточена в пределах области в 1 ГиБ, чтобы обеспечить быстрое насыщение кэша.

График начинается сразу с 40000 IOPS, что явно превышает возможности шести дисков 7200 об/мин. Видимо, перед очередной серией тестов мы не полностью сбросили кэш. Но в данном случае интересно значение после наполнения кэша — это порядка 150000 IOPS. Можно сказать, что если специфика вашей нагрузки заключается в наличии сравнительно небольшой области горячих данных, от которой требуется получить несколько десятков и даже под сотню тысяч IOPS, то стоит подумать об установке в NAS дополнительной памяти. С другой стороны, пара серверных SSD минимального объёма обойдутся ненамного дороже дополнительных 16–32 ГБ памяти, но позволят использовать write-back кэширование, которое гораздо более эффективно при смешанных нагрузках.

Задержка по мере роста числа попаданий в кэш падает ещё сильнее — более чем на порядок, если говорить о перцентилях 99 и 99,99%. Стоит отметить, что при таком интенсивном использовании RAM-кэша довольно заметно нагружается процессор, с незначительных 3% при последовательном доступе до 16%, которые уже стоит учитывать, если ваш NAS почти до предела нагружен различными сервисами.

Virtual Machine Manager

Различных IT-сервисов в наши дни даже небольшим компаниям необходимо много, что приводит к усложнению инфраструктуры и росту затрат на её обслуживание. В некоторых случаях помогает переход на облачные технологии, пока что основным способом оптимизации инфраструктуры остаётся виртуализация. Приобретение серверов с достаточным уровнем производительности сейчас не представляет проблемы: стоимость многоядерных процессоров, оперативной памяти и твердотельных дисков продолжает снижаться, так что пара серверов с достаточным уровнем производительности может позволить себе практически любая организация. Сложнее дела обстоят с программным обеспечением. Бесплатные гипервизоры никуда не делись, но построение на их основе надёжной инфраструктуры для виртуализации, обеспечивающий приемлемый уровень простоя за счёт автоматизации резервного копирования и возможности быстрого перезапуска виртуальных машин на других серверах требует приобретения дополнительных продуктов и трудоёмкого внедрения.

В продуктовой линейке компании Synology уже несколько лет назад появились достаточно производительные модели с 4-ядерными процессорами и поддержкой свыше 8 гигабайт памяти. К многочисленным дополнительным пакетам осталось добавить поддержку виртуализации. В ноябре 2017 появился пакет Synology Virtual Machine Manager. В качестве гипервизора он использует QEMU/KVM с некоторыми доработками. Сильной стороной операционной системы Synology DSM и её дополнительных компонентов является простота и удобство управления. Virtual Machine Manager (далее — VMM) не является исключением — создание виртуальных машин и управление ими реализовано очень удобно и интуитивно понятно. VMM поддерживается не только на достаточно дорогих и производительных NAS в стоечном исполнении, но и на некоторых многочисленных настольных моделях, включая скромные двухдисковые DS218+ с 2-ядерным Celeron. Определённый смысл в этом есть: малый бизнес может начать с недорого настольного NAS, где возможность запуска пары виртуальных машин будет нелишней, затем по мере роста перейти на более производительные модели и быстро перенести существующие виртуальные машины туда.

Функционал VMM. VMM Pro

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

Для запуска VMM необходимо просто установить его из «Центра пакетов», через минуту уже можно приступать к созданию виртуальных машин. Дополнительные настройки сведены к необходимому минимуму. В разделе «Сеть» можно дополнительно создать несколько виртуальных коммутаторов, как внутренних, так и с подключением к внешним сетевым интерфейсам. В разделе «Хранилище» отображаются доступные для хранения виртуальных машин тома — тут можно использовать только локальные тома, отформатированные в BTRFS. Вкладка «Образ» служит для хранения образов установочных дисков и импорта дисков виртуальных машин из форматов других гипервизоров и «сырых образов»: открытый формат OVA, qcow2 (файловый образ для QEMU/KVM), vmdk (VMware), vhd/vhdx (Microsoft), vdi (Oracle Virtualbox). VMM поддерживает множество ОС: настольные и серверные редакции Windows, основные дистрибутивы Linux. С полным списком поддерживаемых ОС можно ознакомиться на сайте Synology.

Настройка резервного копирования выполняется на вкладке «Защита». Там можно настроить автоматическое создание снапшотов и их ротацию. Разумеется, виртуальные машины из снапшотов можно клонировать в новые экземпляры и реплицировать их на другой NAS Synology, но последняя возможность доступна только в редакции VMM Pro.

Оснастка позволяет управлять несколькими VMM из одной точки, но для создания полноценной виртуальной фермы требуется лицензия Virtual Machine Manager Pro. Помимо увеличения максимального количества vCPU и снапшотов, лицензия Pro предоставляет действительно необходимый функционал:

• Удалённая репликации. Локальное хранение снапшотов виртуальных машин сложно назвать надёжным резервным копированием. Репликация полных образов и снапшотов на другой узел является крайне желательной.
• Миграция виртуальной машины на другой хост, в том числе включенной.
• Кластер высокой доступности.

Полный список различий между редакциями доступен на странице продукта. VMM Pro продаётся на основе ежегодно возобновляемой подписки на 3 или 7 узлов. Цена при этом является достаточно низкой в сравнении с конкурирующими продуктами. Для тестирования доступен бесплатный 30-дневный период.

Выделение ресурсов

Процесс создания новой ВМ ничем не отличается от работы с привычными графическими интерфейсами других гипервизоров — выбираем тип операционной системы, вычислительные ресурсы (количество ядер процессора, объём оперативной памяти), виртуальные диски, установочный носитель, сетевые интерфейсы. QEMU/KVM может использовать для контроллера дисков и сети драйверы паравиртуализованных устройств VirtIO, обеспечивающие минимизацию накладных расходов. Современные дистрибутивы Linux поддерживают VirtIO изначально, для Windows требуется установка драйверов — в VMM доступен соответствующий образ ISO.

Стоит отметить важную особенность VMM. Он жёстко ограничивает выделение процессорных ядер и оперативной памяти в соответствии с доступными аппаратными ресурсами. В бесплатной редакции можно выделить количество виртуальных ядер, в два раза превышающее количество потоков процессора, в редакции VMM Pro — в четыре. В обычной реализации гипервизора на базе QEMU/KVM присутствуют два механизма оптимизации работы с памятью: динамическое выделение памяти (memory ballooning) и дедупликация памяти (KSM, Kernel SamePage Merging). Первый позволяет виртуальной машине отдать неиспользуемую часть оперативной памяти гипервизору, своеобразный thin provisioning для оперативной памяти. KSM работает на хосте и периодически сканирует оперативную память в поисках идентичных страниц, заменяя их ссылками на единственный экземпляр. В ситуации, когда запущено несколько виртуальных машин с одинаковыми операционными системами и основными компонентами, использование KSM позволяет сильно уменьшить потребление памяти.

О причинах существования жёсткого выделения ресурсов остаётся только догадываться. Возможно, это лишь временная мера, связанная с особенностью функционала, связанного с кластеризацией, и по мере развития продукта это ограничение будет снято. Также мы надеемся, что в Virtual Machine Manager когда-нибудь появится поддержка приоретизации и квотирования ресурсов на CGroups. Сейчас доступен лишь выбор из шести уровней приоретизации по процессору.

Виртуальный DSM

Кроме импорта виртуальных машин и создания новых VMM предлагает скачать и запустить виртуальный экземпляр ОС Synology DSM. Наличие встроенного гипервизора позволяет закрыть те потребности в сервисах, которые не может удовлетворить большая база пакетов самого DSM. Зачем в таком случае нужен виртуальный DSM? На самом деле, основной сценарий применения достаточно очевиден — предоставление полностью изолированной среды для тестирования или разграничения прав доступа со всеми присущими виртуализации преимуществами в отношении резервного копирования и восстановления. Вы можете предоставить полные права доступа к виртуальному экземпляру DSM другому отделу внутри компании или даже сдать виртуальный экземпляр в аренду.

Вместе с самим NAS в комплекте идёт лицензия на один виртуальный DSM. Дополнительные лицензии приобретаются отдельно, при этом обновления образов предоставляются только на три года.

Active Backup for Business

Мы добрались, пожалуй, до самого интересного пакета Synology под названием Active Backup for Business — унифицированной системы автоматизации резервного копирования для файловых сервисов, физических и виртуальных серверов. Для начала стоит рассказать о функционале. Active Backup for Business (далее — ABB) поддерживает резервное копирование:

• Физических ПК и серверов под управлением Windows (7, 8.1, 10, Server 2008R2, 2012, 2012R2, 2016)
• Сервисов файлового доступа, работающих через SMB, и сервисов Rsync. Поддержки NFS пока что нет, надеемся, что её добавят при дальнейшем развитии продукта.
• Виртуальных машин VMware vSphere 5.0, 5.1, 5.5, 6.0, 6.5, 6.7. Поддерживается доступ как к одиночным узлам ESXi, так и через vCenter.

В vSphere поддерживается резервное копирование только виртуальных дисков. Диски RDM, iSCSI LUN’ы, подключенные через инициатор гостевой ОС и другие виды физических дисков не поддерживаются — для них необходимо использовать агент бэкапа физических серверов.

Работа с ESXi

Важным преимуществом Active Backup for Business является возможность работы не только с vSphere, но и с бесплатным ESXi, так как решения на базе большинства NAS Synology, за исключением разве что топовых FS2017 и FS6400, скорее всего, будут внедряться в компаниях с сильно ограниченных IT-бюджетом.

Мы протестировали несколько сценариев:

• В качестве хранилища для ESXi используется iSCSI-таргет, расположенный на SA3400 и подключенный через два 10-гигабитных интерфейса
• В качестве хранилища используется локальная дисковая подсистема (одиночный SSD Toshiba HK6-R)
• Полное восстановление виртуальной машины на тот же хост
• Полное восстановление на другой хост
• Мгновенное восстановление — образ виртуальной машины разворачивается на сетевом ресурсе NFS
• Конвертация резервной копии в виртуальную машину для запуска в Synology Virtual Machine Manager (мгновенное восстановление в VMM)
• Восстановление отдельных файлов гостевой ОС

Для подключения к vCenter или отдельным хостам с ESXi достаточно добавить необходимые узлы (адреса и логины) на вкладке «Управление VMware vSphere». Для подключения к ESXi необходимо включить на нём доступ по SSH. После настройки подключения все поддерживаемые ABB виртуальные машины будут отображены на соответствующей вкладке, где для них останется создать задачи по резервному копированию — выбрать способ запуска бэкапа (вручную или по расписанию) и срок ротации бэкапов.

Для тестов использовались два сервера с ESXi 6.7 с несколькими виртуальными машинами под управлением Windows Server 2016 Standard, на которых была запущена имитация небольшой нагрузки на диск (чтение/запись блоками 8 КиБ, 50 IOPS). Объём первоначального бэкапа составил 44 ГБ. Для дополнительного теста гранулярного восстановления файлов использовалась ВМ под управлением Linux CentOS 7.

Создание резервной копии ВМ, образ которой размещался на самом NAS ожидаемо оказался самым быстрым из-за отсутсвия внешнего трафика. Процесс создания первоначального полного бэкапа объёмом 44 ГБ занял около 9 минут, что достаточно быстро с учётом нагрузки внутри ВМ и того, что для хранения резервных копий использовался тот же том, что и для размещения iSCSI LUN (при реальном внедрении так, конечно, делать не нужно). Создание последующих инкрементальных копий занимало от 5 до 20 секунд. Полное восстановление через гигабитный линк заняло 22 минуты, причём в качестве целевого можно указать другой хост ESXi. Таким образом, сценарий с бэкапом и восстановлением через Active Backup for Business можно использовать в качестве своеобразной замены функционала платной виртуализации от VMware. Этот способ, конечно, нельзя назвать полноценной заменой кластера высокой доступности vSphere за счёт отсутствия автоматизации, но при ограниченном бюджете такой подход к резервированию узлов инфраструктуры вполне оправдан.

При реальной эксплуатации образы виртуальных машин будут занимать гораздо больший объём, и в итоге полное восстановление нескольких сотен гигабайт может занять более часа. Для этих целей сушествует мгновенное восстановление. Образ виртуальной машины разворачивается непосредственно на самом NAS и презентуется хосту ESXi по NFS.

Со стороны ESXi при этом не требуется выполнять никаких дополнительных действий по подключению нового хранилища. Достаточно в оснастке управления ABB указать хост, на который выполняется восстановление, и нужное хранилище будет настроено автоматически вместе с регистрацией виртуальной машины. Подобный способ восстановления действительно можно назвать мгновенным — на всё ушло около пяти секунд.

Что делать, если вышли из строя не только хранилища (датасторы), но и сами хосты ESXi вышли из строя на длительный срок? На помощь приходит встроенный гипервизор Synology. Выбираем третью опцию — мгновенное восстановление в Virtual Machine Manager. Запускается мастер импорта виртуальной машины, который ничем не отличается по интерфейсу от мастера создания новой ВМ в VMM. Так свободные ресурсы NAS могут быть гораздо скромнее имевшихся на ESXi, то в процессе импорта можно изменить количество ядер и памяти. Единственное, на что стоит обратить пристальное внимание — драйверы паравиртуализованных устройств. Во избежание проблем с совместимостью VMM конфигурирует импортированную ВМ по умолчанию с виртуальным контроллером IDE. Переключение в VirtIO для загрузочного диска в случае Windows может привести к невозможности запуска ОС.

Восстановление в Virtual Machine Manager в нашем случае заняло чуть больше времени — 12 секунд. VMM можно использовать не только в качестве резервного гипервизора, но и для автоматизации тестирования работоспособности резервных копий ВМ. Речь не идёт о сложном скриптовом тестировании сервисов, резервная копия виртуальной машины проверяется только на возможность запуска путём кратковременного запуска в VMM с записью видеоролика.

Работа с порталом восстановления устроена предельно удобно. Нужно лишь запустить пакет Active Backup for Business Portal, в отдельной вкладке браузера откроется интерфейс с деревом каталогов и файлов выбранного бэкапа. Любой файл или каталог можно скачать на локальный ПК из браузера или восстановить в целевую ВМ или физический сервер. Поддерживаются файловые системы NTFS и FAT32, в случае гостевого Linux — дополнительно Ext3 и Ext4.

Работа с физическими серверами и ПК

Для настройки резервного копирования физических машин достаточно установить агент (Active Backup for Business agent, доступен для 32- и 64-разрядных ОС), указать адрес NAS Synology и логин, после чего устройство появится в списке подключённых. Настройка планировщика резервного копирования выполняется так же, как и для виртуальных машин.

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

Мы протестировали восстановление физического сервера под управлением свежеустановленной Windows Server 2012 R2. Объём занятого пространства на всех разделах составлял порядка 20 гигабайт. Нагрузка имитировалась так же, как и в случае с виртуальным сервером — при помощи FIO, генерирующего 50 IOPS случайного доступа блоками по 8 КиБ. На создание первоначальной копии через один 10-гигабитный линк ушло меньше 10 минут, последующие копии создавались за несколько секунд.

Восстановление этой ОС на гипервизор ESXi и на встроенный VMM прошло без проблем. Клонирование и конвертация в VMM заняла меньше одной минуты. Возможность восстановления резервной копии серверных ОС Windows с физического сервера внутри виртуальной машины можно использовать в качестве удобного средства конвертации серверов в виртуальные: достаточно установить агент, запустить резервное копирование и через десятков минут (реально используемые ОС занимают больший объём, чем наши тестовые свежеустановленные экземпляры) получить возможность запуска виртуальной копии. Некоторые проблемы могут возникнуть с производительностью дисковой подсистемы — виртуальная машина по-умолчанию будет использовать виртуальный IDE, и не сможет загрузиться при переключении на VirtIO или PVSCSI из-за отсутсвия драйвера. Тут помогут либо предварительная установка драйвера перед конвертацией или использование паравиртуализованных устройств только для незагрузочных дисков.

Поддержка работы с физическими машинами под управлением Linux ABB появится ещё до конца года. Основная сложность тут заключается в большом разнообразии дистрибутивов с их индивидуальными особенностями, затрудняющими разработку универсального агента, и в отсутствии универсального механизма создания корректных снапшотов. В Windows за это отвечает VSS, в Linux же применяется несколько различных ФС, BTRFS или разметку LVM можно встретить далеко не на каждом экземпляре.

Дедупликация

Active Backup for Business использует достаточно простой алгоритм управления цепочкой резервного копирования под названием «Forever incremental backup». При первоначальном запуске создаётся полная копия, каждый следующий запуск является инкрементальным. При копировании виртуальных машин используется CBT, механизм отслеживания измененных блоков, для физических машин используется VSS.

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

По вышеприведённому скриншоту можно оценить уровень эффективности дедупликации. Общий объём резервных копий одной виртуальной машины с Windows Server 2016, ПК с Windows 10 и трёх физических серверов под управлением Windows Server 2016 и 2012R2 составляет почти 418 гигабайт. Дедупликация сокращает хранимый объём данных до 26,1 гигабайт — примерно в 16 раз.

Разработчикам Synology удалось создать отличный корпоративный продукт для автоматизации резервного копирования. На основе подходящего NAS Synology из корпоративной линейки можно создать относительно недорогую инфраструктуру на основе гипервизора ESXi, обеспечивающую работу небольшой виртуальной фермы с приемлемым уровнем надёжности. Пока что не хватает механизма эффективной репликации и поддержки Hyper-V, но с учётом темпов развития продукта можно ожидать, что этот функционал появится 2019 году.

Hyper Backup

Пакет Hyper Backup предназначен для автоматизации резервного копирования локальных данных NAS Synology. Хранить резервные копии на том же устройстве, пусть и на отдельном томе, рекомендуется только в качестве дополнительного или промежуточного варианта, так что самым интересным в Hyper Backup является широкий выбор «пунктов назначения».

Помимо достаточно очевидного удалённого NAS Synology для резервирования можно использовать любой сервер с rsync или WebDAV. В распоряжении пользователя также есть большой список облачных провайдеров дискового пространства, от Cloud С2 до других публичных облачных сервисов. По мере выхода обновлений пакета этот список будет расширяться.

В плане настроек резервного копирования Hyper Backup предоставляет почти те же возможности по настройке расписания и ротации, что и Active Backup for Business.

Страница:    1 2

Полный текст статьи читайте на Tom's Hardware