Платформа Sharx Base имеет модульную структуру, одним из модулей платформы является модуль Катастрофоустойчивости.

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

Следующие ключевые параметры модуля должны приниматься в расчет при проектировании и разработке такого рода решения:

• Репликация/копирование между кластерами является асинхронной, выполняется на базе снимков данных
• Периодичность копирование снимков данных от 5 минут и выше, значения ниже 5 минут не поддерживаются
• Решение поддерживает копирование снимков в отношении один-к-одному или один-ко-многим, т.е. кластер назначения может быть один или несколько
• Копирование снимков включает в себя сами снимки дисков ВМ, а так же информацию о конфигурации ВМ
• Пользователь самостоятельно определяет список ВМ для копирования, а так же порядок их восстановления/запуска на кластере назначения
• Механизм копирования снимков не отслеживает порядок и успешность запуска ПО конечного пользователя внутри ВМ
• На текущий момент, копирование снимков настраивается через CLI

Необходимая производительность канала связи между кластерами выбирается заказчиком самостоятельно, исходя из требуемых значений RPO/RTO

Рекомендованное значение RTT между двумя центрами обработки данных не хуже 80-100 мс.

Синаксис команд:

<COMMAND> <CL_NAME> [–<PARAM_NAME_1> <PARAM_1>] … [–<PARAM_NAME_N> <PARAM_N>]

где

<COMMAND> - команда CLI
<CL_NAME> - название sdc-cluster
<PARAM_NAME_1> - именование первого аргумента
<PARAM_1> - значение первого аргумента
PARAM_NAME_N> - именование N-ного аргумента
<PARAM_N> - значение N-ного аргумента
[STRING] - подобные скобки означают необязательность указания STRING

Таким образом, минимальная команда для выполнения выглядит так:

<COMMAND> <CL_NAME>

Чтобы уточнинить название кластера <CL_NAME> используйте команду cluster_list:

sdc-core:127.0.0.1:nologin> cluster_list
[
    {
        "cluster": "emu3",
        "vip_host": {
            "name": "dd2d6b36-c621-4d3f-aa79-635723aa507f@10.1.11.23",
            "uuid": "dd2d6b36-c621-4d3f-aa79-635723aa507f",
            "vip": "10.1.11.49"
        }
    }
]

В нашем случае имя кластера emu3.

Если у команды <COMMAND> имеются имеются аргументы, будет показана соответствующая подсказка, например:

sdc-core:127.0.0.1:admin> dr_restore_group_add emu5
Optional attr: ['suffix', 'email']
Please specify (--name) / ['name', 'link']

т.е. у команды dr_restore_group_add имеется два обязательных аргумента name и link и два необязательных - suffix и email.

dradm - специализированная административная учётная запись на КИ для настройки DR

drrest - специализированная учётная запись для операций восстановления на КН

DR – набор мер позволяющий восстановить и продолжить функционирование критичных сервисов инфраструктуры в случае аварии, обусловленной человеческими действиями, или чрезвычайной ситуацией (ЧС).
Применительно к кластерам виртуальных машин это означает восстановление ВМ на резервном кластере, в случае выхода из строя основного.
В основу работы модуля DR положена функциональность создания снапшотов с томов, подключенных к определенным ВМ, и трансфера снапшотов между площадками.

Схема на рис.1 показан принцип взаимодействия резервного Кластера назначения (КН) и основного Кластера источника (КИ).

На КИ существует некоторое количество критичных ВМ которые по определенным признакам (функциональным, приоритету, ответственному) можно объединить в группы репликации. Для ВМ, помещенных в группу репликации, модуль DR SharxBase осуществляет создание снапшотов (Snap) со всех дисков, по заданному в группе расписанию, а так же собирает необходимые данные ВМ (VM properties) на КИ. При помещении ВМ в группу репликации ей задаются параметры восстановления на КН: владелец, сеть, IP-адрес.
Для репликации между кластерами собранных данных и созданных снапшотов используется специально сконфигурированный Линк (Link) между КИ и КН.
Данные поступившие на КН, через Линк, хранятся там с заданной глубиной. Глубина снапшотов - определяемое количество снапшотов, начиная с последнего реплицированного, которые система хранит на случай запроса на восстановление.
На КН необходимо создать Группы Восстановления, которые повторяют (не обязательно) группы репликации по составу, включив в них ВМ из списка реплицируемых, и определить состояние (выключена/включена) ВМ при восстановлении.
В случае наступления обстоятельств, требующих восстановления ВМ, на КН требуется запустить восстановление необходимой Группу Восстановления, указав интервал времени создания снапшота (по умолчанию выбирается последний снапшот), входящий в Глубину Хранения и ожидать восстановления ВМ на КН.

Все операции настройки DR проводятся на Кластер-Источник!

Для настройки запустите sdc-cli из консоли пользователя sdcadmin:

$ sdc-cli

Авторизуйтесь с дополнительной учётной записью dradm:

sdc-core:127.0.0.1:nologin> login dradm

Первым этапом, непосредственно настройки DR, является задание глобальных значений для инсталляции. Эти значения могут переопределяться локально в конкретных случаях (см. ниже).

Для задания глобальных значений используется набор команд dr_global_*:

dr_global_define <CL_NAME> –suffix <SUFFIX> –max_vm_group <VM_GROUP> –max_snap_cnt <SNAP_CNT> –email <EMAIL>

где

CL_NAME – имя sdc-cluster
SUFFIX – Суффикс присваемый создаваемым при ресторе ВМ
VM_GROUP – Максимальное кличество ВМ в одной группе репликации
SNAP_CNT – Количество/глубина хранимых для ВМ снапшотов
EMAIL – почтовый адрес отправкии сообщений о событиях модуля DR

Заданные глобальные значения можно посмотреть командой dr_global_show или же изменить командой dr_global_edit.

Внимание! Изменение глобальных значений на уже созданные группы НЕ влияет.

Линки между кластерами преднастроены, для просмотра используется команда dr_links_show:

sdc-core:127.0.0.1:admin> dr_links_show emu3
 : {
    "emu3-to-emu5": {
        "dst_core": "10.1.14.49:8081",
        "dst_one": "10.1.14.50:2633",
        "dst_one_creds": "b25lYWRtaW46U29uaWMyMDA1",
        "dst_sp_br": "10.1.14.13:3749",
        "dst_sp_id": "bgwa.f",
        "dst_sp_key": "xx6kebfkambzr.848yjgsjmbask.q7wrd61brr17x.ncm2ghqs4ybp8",
        "error": "",
        "src_core": "10.1.11.49:8081",
        "src_one": "10.1.11.10:2633",
        "src_one_creds": "b25lYWRtaW46U29uaWMyMDA1",
        "src_sp_br": "10.1.11.13:3749",
        "src_sp_id": "bgwn.d",
        "src_sp_key": "kh5rzjbrc4t5i.qtcpudy1ayyp6.pn8ehzk6piykb.cpqgxqxp7d7ac",
        "status": "CONNECTED"
    }
}

Обращайте внимание на значения status и error. Имя линка в нашем примере emu3-to-emu5.

Создание и удаление DR-линков выполняется только квалифицированным техническим персоналом по запросу службы эксплуатации..

Для управления группами репликации используются команды группы dr_repl_group_*. В частности, для создания группы необходимо отдать команду:

dr_repl_group_add <CL_NAME> –name <GROUP> –link <LINK> [–cron <CRON>] [–suffix <SUFFIX>] –img_id <IMG_ID> [–depth <DEPTH>] [–email <EMAIL>]

где

GROUP - имя группы
LINK - имя линка для которого создается группа
CRON - периодичность выполенения репликации в ( формате CRON, например "*/15 * * * *" ), не заполняется в случае разовой репликации
SUFFIX - суффикс для группы репликации (переопределит глобальный) 
IMG_ID - идентификатор хранилища типа IMG, на который выполняется репликация томов ВМ
DEPTH - глубина хранения снимков для группы (переопределит глобальный)
EMAIL - адрес для нотификаций (переопределит глобальный)

Составить свое расписание можно, например, тут: https://crontab.guru/#*/20_*_*_*_*

Для управления группами репликации, доступны следующие команды:

dr_repl_group_del - удаление с возможностью очистки снапшотов
dr_repl_group_show - просмотр
dr_repl_group_start - запуск
dr_repl_group_stop - остановка

Команда dr_repl_group_start.

Если настроен график репликации (параметр cron), то репликация начнется не сразу после исполнения команды, а по графику. Когда начнётся следующая репликация, можно увидеть в параметре next_date с помощью команды dr_repl_group_show:

sdc-core:127.0.0.1:admin> dr_repl_group_show emu3
 : {
    "e3g1": {
        "cron": "*/15 * * * *",
        "depth": 2,
        "email": "notificationaccount@yandex.ru",
        "img_id": 1,
        "link": "emu3-to-emu5",
        "next_date": "22/12/2021, 13:15:00",
        "status": "START",
        "suffix": "__emu3",
        "vms": [
            "9",
            "10"
        ]
    }
}

Команда dr_repl_group_del с возможностью очистки снапшотов:

sdc-core:127.0.0.1:admin> dr_repl_group_del emu3
Optional attr: ['delete_snap']
Please specify (--name) / ['name']

Как можно увидеть по подсказке, за очистку снапшотов отвечает параметр delete_snap.

sdc-core:127.0.0.1:admin> dr_repl_snap_show emu3
Optional attr: ['vm_id']
Please specify (--repl_group) / ['repl_group']

Синтаксис команды:

dr_repl_group_del <CL_NAME> –name <GROUP> [–delete_snap 1]

Просмотр снапшотов группы репликации:

sdc-core:127.0.0.1:admin> dr_repl_snap_show emu3 --repl_group e3g1
Optional attr: ['vm_id']
 : {
    "10": {
        "one-img-3-10-0": [
            {
                "creation": "20/12/2021 13:00",
                "id": 95,
                "name": "one-img-3-10-0@95"
            },
            {
                "creation": "22/12/2021 13:15",
                "id": 97,
                "name": "one-img-3-10-0@97"
            }
        ]
    },
    "9": {
        "one-img-2-9-0": [
            {
                "creation": "20/12/2021 13:00",
                "id": 94,
                "name": "one-img-2-9-0@94"
            },
            {
                "creation": "22/12/2021 13:15",
                "id": 96,
                "name": "one-img-2-9-0@96"
            }
        ]
    }
}

Почему так подробно про снапшоты и их удаление?

Удаление ВМ из группы репликации или самой группы репликации вместе со всеми ВМ без удаления снапшотов оставит эти снапшоты на РСХД КН! Удалить их пользователь не сможет самостоятельно, а сами снапшоты будут занимать место на РСХД в размере всей группы с заданной глубиной хранения!

Не забывайте про аргумент –delete_snap 1.

Нельзя удалить группу репликации, если в ней есть ВМ, которые имеются в какой-либо группе восстановления.

Синтаксис команды:

dr_vms_show <CL_NAME> –link <LINK> [–target (src|dst)]

где

LINK - имя линка
target - кластер-источник (src, по умолчанию) или кластер назначения (dst)

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

Добавление ВМ:

dr_repl_vm_add <CL_NAME> –repl_group <GROUP> –vm_id <VM_ID> [–owner <OWNER>] [–vlans net_id=<NET_ID_1>[;ip=<IP_1>][,net_id=<NET_ID_2>[;ip=<IP_2>]][,net_id=…]]

где:

GROUP - имя группы репликации для добавления ВМ
VM_ID - идентификатор ВМ из интерфейса Системы Управления Виртуализацией (СУВ), или из вывода dr_vms_show
OWNER - влaделец ВМ в формате USER:GROUP на КН, если отсутствует, будет создан от имени oneadmin
NET_ID - (опционально) идентификатор сети СУВ на КН, если отсутствует, сетевой интерфейс не будет назначен
IP - (опционально) ip адрес ВМ при восстановлении, в ВМ должен быть установлен пакет контекстуализации

В параметрах может быть указано несколько сетевых интерфесов ВМ, через разделитель «,»

Добавить одну ВМ в несколько групп репликации невозможно.

В данной группе команд так же доступны команды:

dr_repl_vm_show - просмотр
dr_repl_vm_del - удаление с опцией удаления снапшотов

Репликация КИ-КН будет запущена только после старта группы репликации. Для запуска репликации необходимо отдать команду вида:

dr_repl_group_start <CL_NAME> –name <GROUP>

если настроен график репликации (параметр cron), то репликация начнется не сразу после исполнения команды, а по графику.

Для прекращения репликации необходимо отдать команду остановки dr_repl_group_stop, синтаксис аналогичен.

Работа с группами восстановления выполняется командами группы dr_restore_group_*. Для добавления группы восстановления воспользуйтесь командой вида:

dr_restore_group_add <CL_NAME> –name <GROUP> –link <LINK> [–suffix <SUFFIX>] [–email <EMAIL>]

где GROUP - имя группы восстановления

Кроме того, в группе команд имеются:

dr_restore_group_clean - удаляет все ВМ, восстановленные из данной группы
dr_restore_group_del - удаление
dr_restore_group_show - просмотр
dr_restore_group_start - запуск группы
dr_restore_group_stop - остановка

dr_restore_group_clean - удаляет восстановленные ВМ на КН вместе с образами, из которых эти ВМ были клонированы. Не путайте со снапшотами на КН - они останутся на месте. НЕ будут удалены ВМ, которые находятся в состоянии FAILURE, как и образы, с которых они были клонированы.

dr_restore_group_stop - если у какой-то ВМ при восстановлении произошла ошибка (например, была подана команда stop или resume в момент разворачивания), система будет пытаться “оживить” ВМ пока не добьется успеха, посылая при этом сообщения о неуспехе. Остановите группу восстановления, чтобы прекратить вывод сообщений и остановить безуспешные попытки до устранения проблем.

Для операций с ВМ в группе восстановления существует набор комманд dr_restore_vm_*.

Добавить ВМ в группу:

dr_restore_vm_add <CL_NAME> –restore_group <GROUP> –repl_group <REPL> [–vm_id <VM_ID>] [–state <STATE>]

где

GROUP - группа восстановления для добавления ВМ
REPL - группа репликации, из которой будет добавлена ВМ
VM_ID - (опционально) ID ВМ на КИ 
STATE - (опционально) состояние в котором будет восстановлена BM (по умолчанию stop, resume для запущенной/running)

В случае если vm_id отсутствует, все ВМ из группы репликации будут добавлены в указанную группу восстановления.

Другие команды для работы с VM в группе восстановления:

dr_restore_vm_del - удаление
dr_restore_vm_show - просмотр

восстановление ВМ не будет запущено до завершения репликации первого из снапшотов ВМ, входящих в состав группы репликации.

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

Для запуска восстановления по группе используется команда dr_restore_group_start:

dr_restore_group_start <CL_NAME> –name <GROUP> [–test <TEST>] [–tfrom <TFROM>] [–tend <TEND>]

где:

TEST(опционально) - запустить восстановление в режиме теста, созданые ВМ удалятся после успешного запуска; принимает значение 1
TFROM(опционально) - указывает начало интервала, в котором осуществляется поиск времени старта репликации снапшота, из которого будет восстановлена ВМ на КН
TEND(опционально) - по аналогии с предыдущим, но указывает окончание интервала для поиска, формат аналогичен предыдущему

Формат TFOM и TEND таков: «dd/mm/YYYY HH:MM», например: «22/12/2021 14:00». Не указывайте точные значения для времени, т.е., если вас интересует снапшот с датой создания, например, «22/12/2021 14:00», добавьте одну минуту к конечному времени, чтобы в итоге получилось –tend «22/12/2021 14:01».

Используйте dr_restore_group_stop чтобы прервать операцию восстановления по группе.

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

dr_repl_queue_show <CL_NAME> –repl_group <GROUP>

• текущие операции репликации по выбранному линку:

dr_repl_progress_show <CL_NAME> –link <LINK>

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

dr_restore_queue_show <CL_NAME> –restore_group <GROUP>

При наступлении событий, приведших к отказу КИ и требующих восстановления ВМ на КН зайдите в CLI на КН, авторизуйтесь с учётной записью drrest и запустите команду восстановления по группе.

Просмотреть список групп восстановления можно командой dr_restore_group_show.

• При множественных операциях восстановления реплицированных ВМ на КН, важно помнить, что после ручного удаления восстановленной ВМ, так же требуется удалить images (образы) связанные с удаляемой ВМ, из пункта Images раздела Datastores, во избежание переполнения РСХД КН.
• Для репликации «объемных» ВМ может потребоваться длительное время, определяемое доступной пропускной способностью каналов связи.
• Очередность добавления ВМ в группу репликации определяет очередность репликации снапшотов.
• Что делать, если вы вдруг удалили ВМ, но забыли удалить снапшоты? Создайте новую группу репликации и добавьте в нее эти ВМ. После этого старые снапшоты можно будет просмотреть командой dr_repl_snap_show. Удалите эту группу репликации с параметром –delete 1.

Схематично отправку оповещений можно описать следующим образом:

Плагин → Карта маршрутов → Сервер пересылки сообщений

Все операции настройки проводятся на Кластер-Источнике

Для настройки запустите sdc-cli из консоли пользователя sdcadmin:

$ sdc-cli

Авторизуйтесь:

sdc-core:127.0.0.1:nologin> login dradm

Синтаксис команды для добавления нового сервера пересылки сообщений:

notif_smtp_add <CLUSTER_NAME> –name <SMTP> –url <URL> –is_tls <IS_TLS> –desc <DESC> –user <USER> –passwd <PASSWD> –from_addr <FADDR> –subject <SUBJ>,

где

NAME - имя кластера
SMTP - уникальное имя
URL - адрес SMTP сервера в формате HOST:PORT
IS_TLS - 1/0 - использовать tls 
DESC - описание
USER - пользователь (если используется авторизация)
PASSWD - пароль (если используется авторизация)
FADDR - почта отправителя (по умолчанию)
SUBJ - тема письма (по умолчанию)

Обязательно проверьте корректность порта сервера!

Пример команды для работы с почтовым сервером Яндекс:

sdc-core:127.0.0.1:dradm> notif_smtp_add <CLUSTER_NAME> –name notif@yandex –url smtp.yandex.ru:587 –is_tls 1 –user <useraccount> –passwd <PASSWORD> –from_addr <useraccount>@yandex.ru –subject «Message from notif@yandex»

Для настройки Yandex-почты в качестве сервера оповещения надо включить галочку “Портальный пароль”

Проверить настройки:

sdc-core:127.0.0.1:dradm> notif_smtp_show <CLUSTER_NAME>

 : {
    "notif@yandex": {
        "desc": null,
        "from_addr": "<useraccount>@yandex.ru",
        "host": "smtp.yandex.ru:587",
        "is_tls": "1",
        "passwd": "dFRIWjc0cFZkSm50V1o1",
        "subject": "Message from notif@yandex",
        "template": null,
        "user": "<useraccount>"
    }
}

Отправить тестовое сообщение на этот же адрес:

sdc-core:127.0.0.1:dradm> notif_smtp_test <CLUSTER_NAME> –smtp notif@yandex –to <useraccount>@yandex.ru –body «This is the test message»

Optional attr: ['from', 'subject']
 : ok

Чтобы удалить запись о сервере пересылки сообщений, используйте команду:

sdc-core:127.0.0.1:dradm> notif_smtp_del <CLUSTER_NAME> –name <notif@yandex>

Для настройки маршрута отправки оповещений плагина DR используется команда:

sdc-core:127.0.0.1:dradm> notif_route_add <CLUSTER_NAME> –source dr –target notif@yandex

здесь:

source указывает на плагин, который отправляет сообщения,

target указывается уникальное имя smtp-сервера (параметр name команды notif_smtp_add).

Просмотреть текущие маршруты можно командой:

sdc-core:127.0.0.1:dradm> notif_route_show <CLUSTER_NAME>

 : {
    "dr": "notif@yandex"
}

Для удаления маршрута используйте команду

sdc-core:127.0.0.1:dradm> notif_route_del <CLUSTER_NAME> –source dr

При запуске группы восстановления на одном из этапов может появляться ошибка:

Это не влияет на процесс восстановления, но генерирует сообщение об ошибке.

Работы над устранением ведутся.