Подключение к публичному облачному хранилищу через Backup Gateway

Подключение к публичному облачному хранилищу через Backup Gateway#

Backup Gateway позволяет Кибер Бэкап Облачный или Кибер Бэкап использовать для хранения резервных копий публичные облачные сервисы и локальные хранилища объектов:

  • Yandex Object Storage;

  • VK Cloud Storage;

  • SberCloud OBS;

  • CloudMTS S3 Object Storage;

  • Amazon S3;

  • IBM Cloud;

  • Alibaba Cloud;

  • IIJ;

  • Cleversafe;

  • Cloudian;

  • Microsoft Azure;

  • Объектное хранилище Swift;

  • Softlayer (Swift);

  • Google Cloud Platform;

  • Wasabi;

  • другие решения, использующие S3.

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

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

  • Ice в Yandex Object Storage;

  • Cold в SberCloud OBS;

  • Infrequent Access в Amazon S3;

  • Cool Blob Storage в Microsoft Azure;

  • Nearline и Coldline Storage в Google Cloud Platform.

Классы архивных хранилищ, такие как Amazon S3 Glacier, Azure Archive Blob или Google Archive, не могут использоваться для резервного копирования, поскольку не предоставляют мгновенного доступа к данным.

Большая задержка при доступе (несколько часов) делает технически невозможным просмотр архивов, быстрое восстановление данных и создание инкрементных резервных копий. Хотя архивные хранилища, как правило, очень экономичны, следует учитывать, что существуют различные факторы, определяющие стоимость. В действительности общая стоимость публичного облачного хранилища складывается из платы за хранение данных, операции, трафик, извлечение данных, досрочное удаление и т. д. Например, сервис архивного хранилища может брать полугодовую стоимость хранения всего за одну операцию восстановления данных. Если предполагается более частый доступ к данным, то добавочные расходы значительно повышают общую стоимость хранилища. Чтобы избежать низкой скорости извлечения данных и сократить расходы, рекомендуем использовать Кибер Бэкап Облачный для хранения данных резервного копирования.

Ограничения

  • При работе с публичным облаком Backup Gateway использует локальное хранилище для промежуточного копирования, а также для хранения служебной информации. Это означает, что данные, предназначенные для загрузки в публичное облако, сначала сохраняются локально и только после этого отправляются в место назначения. По этой причине для сохранности данных крайне важно, чтобы локальное хранилище было постоянным и избыточным. Использование временных дисков может привести к потере данных.

  • Если вы планируете хранить резервные копии в облаке Amazon S3, учтите, что Backup Gateway может иногда блокировать доступ к таким резервным копиям до согласования облака Amazon S3. Это означает, что Amazon S3 может иногда возвращать устаревшие данные, поскольку системе требуется время, чтобы открыть доступ к последней версии данных. Backup Gateway определяет такие задержки и защищает целостность резервной копии, блокируя доступ на время обновления облака.

    • Убедитесь, что в локальном кластере хранилища достаточно логического пространства для промежуточного копирования. Например, при ежедневном резервном копировании обеспечьте достаточно места для резервных копий как минимум на 1,5 дня. Если размер ежедневной резервной копии составляет 2 ТБ, необходимо как минимум 3 ТБ логического пространства. Требуемый объем неформатированного пространства будет различаться в зависимости от режима кодирования: 9 ТБ (3 ТБ на сервер) в режиме 1+2, 5 ТБ (1 ТБ на сервер) в режиме 3+2 и т. д.

    • Для каждого кластера хранилища резервных копий требуется отдельный контейнер объектов.

  • Избыточность за счет репликации не поддерживается для хранилищ резервных копий.

Предварительные требования

  • В целевом хранилище достаточно места как для существующих, так и для новых резервных копий.

  • Убедитесь, что на каждом сервере, который будет присоединен к кластеру хранилища резервных копий, открыт TCP-порт 44445 для исходящих подключений к Интернету, а также для входящих подключений от продукта Кибер Бэкап.

Выбор публичного облака в качестве места назначения резервных копий

  1. На экране Инфраструктура → Сети убедитесь, что в сети, которые вы собираетесь использовать, добавлены типы трафика Резервное копирование (ABGW) внутр. и Резервное копирование (ABGW) внешн.

  2. Откройте экран Сервисы хранилища → Резервные копии и нажмите Создать хранилище резервных копий.

  3. На шаге Место назначения резервной копии выберите Облачный сервис.

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

  5. На шаге Облачный сервис укажите информацию, связанную с поставщиком облачного сервиса.

    1. Выберите поставщика облачного сервиса. Если ваш сервис совместим с S3, но отсутствует в списке, попробуйте AuthV2-совместимый (S3) или AuthV4-совместимый (S3) сервис.

    2. В зависимости от поставщика укажите Регион, URL аутентификации (Keystone) или URL точки доступа.

    3. При использовании объектного хранилища Swift укажите версию протокола аутентификации и необходимые для него атрибуты.

    4. Укажите учетные данные пользователя. При использовании Google Cloud выберите файл JSON с ключами для загрузки.

    5. Укажите папку (корзину, контейнер) для хранения резервных копий. Папка должна быть доступна для записи.

      Для каждого кластера хранилища резервных копий следует использовать отдельный контейнер объектов.

    6. Для объектного хранилища типа AuthV4-совместимый (S3) укажите, какую модель адресации необходимо использовать для доступа.

      • Virtual-hosted style URLs. Адреса вида https://mybucket.s3.example.com/myobject.txt. Предназначена для облачных S3-хранилищ.

      • Path-style URLs. Адреса вида https://s3.example.com/mybucket/myobject.txt. Предназначена для локальных S3-хранилищ.

      Модель Virtual-hosted style URLs используется по умолчанию. Для использования модели Path-style URLs установите флажок Использовать адресацию path-style.

    7. Нажмите кнопку Далее.

    _images/backup_public_cloud1_ac.png

  6. На шаге Политика хранения выберите нужный уровень, область отказа и режим избыточности данных. Избыточность за счет репликации не поддерживается для Backup Gateway. Дополнительные сведения см. в Руководстве администратора. Затем нажмите кнопку Далее.

    image2

  7. На шаге DNS укажите внешнее доменное имя для хранилища резервных копий, например backupstorage.example.com. Агенты резервного копирования будут использовать это доменное имя и TCP-порт 44445 для передачи данных в хранилище. Затем нажмите кнопку Далее.

    Важно

    • Настройте свой DNS-сервер в соответствии с примером, приведенным в панели администратора.

    • При каждом изменении сетевой конфигурации серверов в кластере хранилища резервных копий корректируйте записи DNS соответствующим образом.

    image1

    Примечание

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

  8. На шаге Учетная запись Киберпротект укажите следующую информацию для вашего продукта:

    • URL-адрес портала управления облаком или имя хоста/IP-адрес и порт локального сервера управления (например, http://192.168.1.2:9877);

    • данные партнерской учетной записи в облаке или учетные данные администратора организации на локальном сервере управления.

  9. На шаге Сводка просмотрите конфигурацию и нажмите Создать.