О том, как масштабировать репозитарии, я уже писал http://www.veskin.ru/2012/07/veeam-backup-v6x.html.
С хранением резервных копий все также достаточно гибко – возможны различные варианты, но у каждого есть свои нюансы.
Само собой резервные копии желательно хранить вне пределах виртуальной инфраструктуры, чтобы избежать «одной корзины» (или «single point of failure»). Так что так или иначе желательно иметь отдельный массив под резервные копии. Все остальное зависит от задачи, которую необходимо решить.
Репозитарии – серверы, которые осуществляют запись на диск – могут быть различные по типу установки:
a) Windows
b) Linux
По месту хранения:
a) Локальный диск – то, что видно сервером как локальные диски: локальные диски, DAS-полка с дисками, FC- и iSCSI-хранилища, USB-накопители и т.п.
b) CIFS-шара
c) NFS-шара
Примечания:
1. Почти все это можно между собой комбинировать.
2. Репозитарий – по большому счету это не сервер, а место для складирования резервных копий. Т.е. если у одного сервера три диска, и еще он будет писать на две сетевые CIFS-шары, то это буде 5 репозитариев.
3. Для NFS-хранилищ мы рекомендуем использовать дополнительную linux-машину, к которой смонтировать NFS диск. Эта машина будет репозитарием на котором будет работать скрипт для записи. Возможно презентовать NFS как диск и на Windows-машину с установленными UNIX Tools, но этот сервер не сможет из-за конфликтов выступать как vPower NFS сервер для мгновенного восстановления, SureBackup и VirtualLab.
4. vPower NFS работает только на Windows серверах. Но можно использовать различные серверы для хранения и для vPower NFS (т.е. храним копии на одном сервере, а восстанавливаем через третий).
5. D2D стораджи поддерживаем. Запись/восстановление работает хорошо, при этом происходит дополнительное сжатие со стороны СХД. НО! vPower NFS может в этом случае работать крайне медленно. Дело в том, что D2D не быстро работает с данными при случайном доступе. На этот случай у нас имеются специальные настройки для оптимизации работы с дедуплицирующими устройствами.
2. Виртуальному репозиторию, на мой взгляд, лучше всего подойдут:
a. Презентованный iSCSI LUN с хранилища отличного от хранилища защищаемых ВМ.
b. NFS на линукс-репозитарии с vPower NFS на другом сервере (например, основном Veeam Backup).
c. RAW диск (VMware RDM) на хранилище, отличном от хранилища защищаемых ВМ.
3. Физическому репозитарию подойдут все виды хранилищ, но я рекомендую тогда использовать Windows-сервер, и в качестве места хранения не использовать NFS в пользу возможности создания vPower NFS на нем. В этом случае имеем ряд преимуществ:
Напомню про бэкап прокси. Они могут оставаться виртуальными вне зависимости от выбранного вида инсталляции репозитария. Кроме того, их в качестве виртуальных машин проще масштабировать (добавлять новые ВМ проще, чем новые физические машины) с тем, чтобы запускать несколько заданий на копирование параллельно.
С хранением резервных копий все также достаточно гибко – возможны различные варианты, но у каждого есть свои нюансы.
Само собой резервные копии желательно хранить вне пределах виртуальной инфраструктуры, чтобы избежать «одной корзины» (или «single point of failure»). Так что так или иначе желательно иметь отдельный массив под резервные копии. Все остальное зависит от задачи, которую необходимо решить.
Репозитарии – серверы, которые осуществляют запись на диск – могут быть различные по типу установки:
a) Виртуальные
b) Физические
По типу ОС:b) Физические
a) Windows
b) Linux
По месту хранения:
a) Локальный диск – то, что видно сервером как локальные диски: локальные диски, DAS-полка с дисками, FC- и iSCSI-хранилища, USB-накопители и т.п.
b) CIFS-шара
c) NFS-шара
Примечания:
1. Почти все это можно между собой комбинировать.
2. Репозитарий – по большому счету это не сервер, а место для складирования резервных копий. Т.е. если у одного сервера три диска, и еще он будет писать на две сетевые CIFS-шары, то это буде 5 репозитариев.
3. Для NFS-хранилищ мы рекомендуем использовать дополнительную linux-машину, к которой смонтировать NFS диск. Эта машина будет репозитарием на котором будет работать скрипт для записи. Возможно презентовать NFS как диск и на Windows-машину с установленными UNIX Tools, но этот сервер не сможет из-за конфликтов выступать как vPower NFS сервер для мгновенного восстановления, SureBackup и VirtualLab.
4. vPower NFS работает только на Windows серверах. Но можно использовать различные серверы для хранения и для vPower NFS (т.е. храним копии на одном сервере, а восстанавливаем через третий).
5. D2D стораджи поддерживаем. Запись/восстановление работает хорошо, при этом происходит дополнительное сжатие со стороны СХД. НО! vPower NFS может в этом случае работать крайне медленно. Дело в том, что D2D не быстро работает с данными при случайном доступе. На этот случай у нас имеются специальные настройки для оптимизации работы с дедуплицирующими устройствами.
Обзор различных вариантов с учетом всего вышеописанного.
1. Если сервер хранения (репозитарий) виртуальный, то возможны такие варианты: презентовать еще один vmdk для резервных копий. Но, так как хранимые копии будут внутри vmdk-файла, у этого варианта есть несколько явных недостатков:- Инкапсуляция. "То, что одним помогает петь, другим - мешает танцевать" (шутка про микрофон ©КВН).
Если что-то нехорошее случится в инфраструктуре, что затронет и ВМ репозитория, и срочно понадобятся резервные копии, то vmdk необходимо подключать только к другим ВМ, к физическому серверу просто так подцепить виртуальный диск не получится. - Несмотря на надежноcть VMFS и vmdk – это две дополнительные точки отказа, и инструментов восстановления на рынке не так много.
- Ограничение vmdk – 2 ТБ на диск. Сказывается на хранимых объемах.
- Если ошибочно забэкапить ВМ репозитория на саму себя (через снапшот, думаю, это возможно), может получится некрасивая рекурсия :)
2. Виртуальному репозиторию, на мой взгляд, лучше всего подойдут:
a. Презентованный iSCSI LUN с хранилища отличного от хранилища защищаемых ВМ.
b. NFS на линукс-репозитарии с vPower NFS на другом сервере (например, основном Veeam Backup).
c. RAW диск (VMware RDM) на хранилище, отличном от хранилища защищаемых ВМ.
3. Физическому репозитарию подойдут все виды хранилищ, но я рекомендую тогда использовать Windows-сервер, и в качестве места хранения не использовать NFS в пользу возможности создания vPower NFS на нем. В этом случае имеем ряд преимуществ:
- Сервер не зависит от жизнеспособности VMware. Если что случится с виртуальной инфраструктурой, то сервер останется живым с доступными резервными копиями. (опять же если конечный LUN не будет тем же массивом, на котором находятся сами ВМ)
- Сервер не зависит от жизнедеятельности VMware. Все нагрузки на запись данных (CPU, ввод-вывод данных на диск) будут идти вне хостов ESX.
- При восстановлении vPower NFS подключается извне хостов, и соответственно сетевой трафик не циркулирует внутри хостов ESX, как это может происходить в случае с виртуальными репозитариями.
- К этому серверу можно подключить еще и FC, и копировать по сети SAN (Direct SAN Access Proxy), и забрать на себя еще и нагрузку по извлечению данных, а тем самым исключить вообще сетевой трафик и другие влияния на виртуальную инфраструктуру.
Напомню про бэкап прокси. Они могут оставаться виртуальными вне зависимости от выбранного вида инсталляции репозитария. Кроме того, их в качестве виртуальных машин проще масштабировать (добавлять новые ВМ проще, чем новые физические машины) с тем, чтобы запускать несколько заданий на копирование параллельно.
Комментариев нет:
Отправить комментарий