Бэкапы нужно иметь. Желательно, в нескольких местах.

Я думаю, что каждый администратор Veeam Backup & Replication замечал в консоли управления кнопку «Add Service Provider». На Хабре есть несколько хороших статей, которые демонстрируют, как использовать эту кнопку по назначению и как начать складывать бэкапы Veeam не только у себя, но и в облако, предоставленное сервис-провайдером.

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

Veeam предоставляет, на мой взгляд, очень удобную возможность хранения резервных копий и реплик off-site, на стороне сервис-провайдера, который предоставляет для этих целей свои дисковые и вычислительные мощности. Наибольшим удобством для клиента является то, что все подключения к сервис провайдеру выполняются из привычной администратору консоли BR и легким движением мыши он получает целевой репозиторий для бэкапов, находящийся где-то далеко.
Администратор при этом использует привычные ему задачи Backup Job и Backup Copy Job, зная при этом, что если он потеряет основной бэкап, всегда можно будет восстановиться из копий, находящихся на стороне сервис-провайдера.

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

Начну, пожалуй, со схемы, которая объясняет принцип работы Cloud Connect:


Левая часть — это наши клиенты. Пользователи Veeam BR, которые отправляю свои бэкапы на сторону сервис-провайдера.

Правая часть — сервис провайдер. Его инфраструктура состоит из следующих компонент:

  • Veeam Backup Server — сервер, управляющий облаком, клиентами, дисковыми и вычислительными ресурсами;
  • Veeam Backup Repository — привычный и знакомый сервер с подключенными к нему хранилищами. В данном случае здесь располагаются бэкапы клиентов;
  • Veeam Cloud Gateway — Точка входа клиента. Именно через этот шлюз происходит загрузка бэкапов от клиента в репозиторий сервис-провайдера. Таких гейтвеев может быть несколько;
  • Опционально WAN-оптимизатор с двух сторон.

Взаимодействие между клиентом и сервис провайдером производится по зашифрованному каналу через один единственный порт.

Теперь, когда видно, как это выглядит со стороны, посмотрим на сторону сервис провайдера. В своей тестовой среде я использую три сервера для облачного хранилища и одного клиента:

  • Veeam Backup Server;
  • Veeam Backup Repository;
  • Veeam Cloud Gateway;

Для чистоты испытания, все компоненты Cloud Connect находятся в отдельной от клиентов сети. Сервер Cloud Gateway имеет второй интерфейс, который смотрит в сеть, доступную клиентам (в идеале это WAN, но не в моем случае).

Стоит заметить, что серверу Cloud Gateway не обязательно иметь второй интерфейс, который доступен извне. Он прекрасно уживается в DMZ за NATом (Так и должно быть всегда, imho), пробросить снаружи требуется всего один порт.

Список портов, которые может использовать Veeam.

Теперь углубимся в настройку всего этого дела:
В первую очередь необходимо проинсталлировать классический сервер Veeam Backup & Replication с одним исключением. На данном сервере должна использоваться другая лицензия, лицензия Cloud Connect Provider. Подробнее про лицензии для сервис-провайдеров.

После инсталляции сервера BR и добавления лицензии сервис-провайдера, сразу можно заметить отличие. Ко всему прочему мы получаем новую закладку «CLOUD CONNECT»:


Предварительно, я подключил к серверу Veeam две виртуальные машины, с одной из которых я подключил репозиторий, а вторая будет использована для Cloud Gateway. В итоге, структура Veeam выглядит следующим образом:


Репозитории:


Теперь займемся настройкой нашего облачного хранилища. В первую очередь необходимо добавить сертификат, который будет использоваться для канала общения с клиентом. Можно сгенерировать свой сертификат, использовать уже импортированный, либо использовать файл сертификата. Делается это пунктом «Manage Certificates» из вкладки «CLOUD CONNECT». Я буду использовать первый пункт и создам самоподписанный сертификат:



Далее Veeam предложит ознакомиться с сертификатом. На этом его создание\импорт закончено.

Следующим шагом необходимо добавить Cloud Gateway, через который клиенты будут получать доступ к ресурсам для размещения своих резервных копий. Необходимо использовать пункт меню «Add Cloud Gateway»:

В первую очередь необходимо выбрать сервер, на который будет выступать в роли Cloud Gateway и на который будут установлены необходимые пакеты, а так же указать порт, через который сервер будет принимать подключения от клиентов (На этот порт необходимо настроить NAT, если используется):


Следующим шагом необходимо указать тип подключения нашего Gateway к сети. Используется прямое подключение, либо мы находимся за NAT?.. В моем случае я использую прямое подключение через Ethernet 2:


Если Gateway находится за NAT, необходимо указать адрес NAT устройства.

Далее Veeam сверяет настройки и сообщает о том, что будет проинсталлирован сервис Cloud Gateway на целевую машину, указанную в начале. Дождавшись окончания установки, убеждаемся, что у нас появился новый шлюз доступа:


Данная возможность не имела бы смысла, не будь у нас клиентов. Следующим шагом необходимо создать учетную запись клиента и выделить ему пул ресурсов. Учетная запись передается клиенту и с ней он осуществляет подключение к сервис-провайдеру.

Добавление клиентов происходит на пункте «Tenants» > «Add Tenant»:

При добавлении нового клиента указывается его учетная запись и, соответственно, пароль для доступа. Далее указываются ресурсы, которые предоставляются пользователю. Они могут быть как дисковые, так и вычислительные. Поскольку я использую в данном примере только резервное копирование, я указываю только дисковые ресурсы (Backup Storage). Так же можно указать срок действия контракта, по истечению которого пользователь не сможет подключаться:


Далее мы можем ограничить максимальную пропускную способность клиента:


На последнем этапе мы добавляем репозитории, которые будут видны у пользователя, а так же указываем квоту, доступную пользователю в данных репозиториях. В примере я добавлю пользователю репозиторий на 20GB:



Здесь же можно подключить WAN-аккселератор, если он необходим клиенту. В случае, если клиенту необходимо добавить два репозитория, расположить их можно будет только на разных репозиториях, подключенных к нашему серверу Veeam BR.

Сверив суммарные настройки, нажимаем «ок». Теперь на закладке «Tenants» мы видим нашего клиента:



А на закладке Backup Storage можно наблюдать, как клиенты использую предоставленное им дисковое пространство:


На этом все, настройка Veeam со стороны сервс-провайдера закончена. Проверим, получится ли клиенту использовать наши ресурсы.

На втором сервере BR я выбираю «Add Service Provider» и указываю адрес Ethernet 2 моего Cloud Gateway, который был настроен выше (В случае NAT, необходимо указывать адрес устройства, выполняющего проброс портов). А еще лучше завести DNS запись для данного адреса:


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


Если все «ок», клиент будет видеть список предоставленных ему ресурсов. Как можно заметить, мы видим выделенные ранее 20GB:


Теперь клиент будет видеть адрес нашего Cloud Gateway в списке «Service Providers», а репозиторий с именем «repo1_20g» будет виден в списке репозиториев.

Данный репозиторий можно использовать и для обычной задачи резервного копирования и для задач типа Backup Copy. Я создам и запущу обычную задачу, проверим, что будет видеть в данном случае сервис провайдер.

Как только клиент запускает задачу, в качестве цели у которой указан репозиторий сервис-провайдера, через консоль управления провайдер может увидеть состояние запущенной клиентом задачи, а так же объем переданных в данный момент данных:


При этом провайдер не видит виртуальные машины, которые резервируются, и другую ценную для клиента информацию. Для большей уверенности в том, что к бэкапам никто не притронется, в свойствах задачи резервного копирования имеется возможность включить шифрование. Делается это в пункте «Advanced > Storage»:



Две задачи. Одна защищена паролем, другая — нет.

Со стороны пользователя есть одно ограничение. Максимальное количество потоков, которые могут быть запущены на один репозиторий — 1. Т.е., даже если в прокси включено 10 потоков, резервироваться виртуальные машины будут в порядке очереди, а не по 10 сразу. Больше об ограничениях здесь.Чтобы иметь возможность запускать несколько потоков, необходимо несколько репозиториев, предоставленных провайдером, а так же несколько задач резервного копирования.
В остальном же, процесс резервного копирования\восстановления при использовании облака аналогичен процессу восстановления из обычного репозитория, за исключением возможности использовать Instant Recovery.

Вот вроде и все, что я планировал написать про резервное копирование в облако Veeam. Хотелось бы еще раз добавить, что как по мне, это удобный вариант для соблюдения правила 3-2-1. Ознакомившись с данной статьей, быть может кто-то захочет стать провайдером, а кто-то начнет доверять провайдерам хранение своих резервных копий.
Поделиться с друзьями
-->

Комментарии (11)


  1. Loxmatiymamont
    18.10.2016 15:46

    >>WAN-оптимизатор
    Так акселераторы ещё никто не обзывал. Милота 80го уровня =)


    1. mikkisse
      18.10.2016 16:17

      Простите мне мое невежество. Конечно-же акселераторы :)


      1. navion
        19.10.2016 12:45

        А расскажите про него подробнее, у кого Veeam лицензирует движок?


        1. mikkisse
          19.10.2016 12:53

          Вот ответ на эту тему:
          Enterprise edition supports Built-in WAN Acceleration to Veeam Cloud Connect targets only. Enterprise Plus edition supports Built-in WAN Acceleration to any target.

          WAN акселератор начинает работать с лицензии Enterprise, но в этой версии он может работать только при бэкапах в клауд. Чтобы развернуть акселераторы исключительно для себя и в своей инфраструктуре, нужна уже лицензия Enterprise Plus.


          1. navion
            19.10.2016 13:28

            Меня интересует кто разработчик движка WAN-акселератора (Aspera, Silver Peak, Riverbed и т.д.)?


            1. mikkisse
              19.10.2016 13:50
              +1

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


              1. Loxmatiymamont
                19.10.2016 15:37
                +1

                Вроде да, но нет. Кеш акселераторов формируется только во время передачи данных между двумя точками. Во время простого бекапа ничего не кешируется.
                Хотя можно ручками сделать pre-population. Это помогает избежать передачи полного бекапа во время первого прогона.


                1. mikkisse
                  19.10.2016 15:44

                  Я, наверное, не умею изъясняться, но это я и имел в виду. Спасибо за дополнение.



            1. sysmetic
              22.10.2016 11:47
              +1

              Встроенный WAN-акселератор — это собственная разработка Veeam. Его отличие от универсальных WAN акселераторов в том, что встроенный WAN акселератор заточен сугубо под формат данных, которые передает через сеть именно Veeam Backup (и он не может быть использован для чего-то другого). Кратко встроенный акселератор можно описать так: по сути это кеш ранее переданных блоков резервных копий на обеих сторонах сети. Если повторно передается ранее переданный блок, Veeam это определяет (по хэшу блока) и передает через сеть только хэш блока данных, но не сами данные — данные на таргете извлекаются из кеша блоков на таргетной стороне. Именно это и проводит к сокращению сетевого трафика.


              1. navion
                22.10.2016 16:01

                Спасибо за пояснение, получается этакая распределённая дедупликация.