Вводные данные
Исходная инфраструктура:
-
Физический сервер на Windows Server с ролью Hyper-V.
-
Сервер 1С.
-
СУБД SQL Server.
Также имеем несколько информационных баз 1С и около 70 пользователей системы.
Необходимо обеспечить катастрофоустойчивость 1С (обеспечение непрерывности бизнес-процессов в результате природных, техногенных катастроф или умышленных/случайных действий людей) и возможность восстановить работу системы в кратчайшее время в случае полного или частичного выхода из строя серверного оборудования.
Решение
Первый вариант, который был рассмотрен – установка второго физического сервера и настройка репликации Hyper-V. Данный подход имеет два важных недочета:
-
Требуется выделение бюджета
-
Не решается вопрос с катастрофоустойчивостью
Альтернативное решение – репликация серверов в дата-центр и запуск их в случае отказа локальной инфраструктуры.
Для реализации выбрали Azure Site Recovery – служба репликации ресурсов в рамках Microsoft Azure.
Оформив подписку на Azure, идем на портал и переходим в раздел Группы ресурсов.
Необходимо создать Группу ресурсов.
После успешного создания переходим в группу и добавляем сервис Backup and Site Recovery (OMS).
Заполняем параметры службы.
Дожидаемся создания службы ASR в нашей подписке и переходим к созданному сервису.
Теперь мы можем приступить к настройке Site Recovery. Переходим в раздел Начало работы, Site Recovery и приступаем к подготовке инфраструктуры. Сначала нам необходимо описать текущую инфраструктуру и установить агента.
Azure предложит нам скачать программу-агента, необходимую для репликации, и ключ регистрации хранилища. Скачав агента, приступаем к его установке на физический сервер с ролью Hyper-V.
Процесс установки простой и состоит из нескольких этапов. Один из них – регистрация хранилища. Для регистрации нажимаем соответствующую кнопку.
Указываем путь к загруженному ранее ключу хранилища.
Далее, мы можем указать настройки подключения к сети и т. д. Если все прошло правильно – мастер установки закончит работу.
На портале Azure через 15 – 30 мин появится наш физический узел в списке серверов Hyper-V.
Возвращаемся в раздел Начало работы, Site Recovery и продолжаем.
На шаге 4 мы можем настроить и связать политику репликации.
На завершающем шаге Azure позволяет скачать планировщик, который может оценить готовность локальной инфраструктуры и пропускную способность каналов связи.
Закончив подготовку инфраструктуры, переходим к настройке репликации приложения.
Выбираем источник, целевой объект, группу ресурсов и т. д. Фактически, на этом шаге мы определяем, какие именно существующие виртуальные шины будут реплицироваться.
После завершения настройки репликации и политики мы можем запустить синхронизацию данных. Процесс длительный, так как происходит синхронизация локальных ресурсов и виртуальных в Azure.
После успешной репликации необходимо провести тестовую отработку отказа. Она бывает трех видов:
-
Отработка отказа в Azure – перенос виртуальных машин из Hyper-V в Azure.
-
Отработка отказа на локальный сайт – синхронизация данных из Azure с Hyper-V и перенос виртуальных машин в локальную инфраструктуру.
-
Обратная репликация – возврат репликации виртуальных машин из локального расположения в Azure.
На этом весь процесс настройки репликации заканчивается.
Какие вопросы возникли
Когда мы настраивали репликацию виртуальных машин с Azure Site Recovery возник вопрос – как быть с SQL Server? Какое минимальное время между репликами? Какими будут RPO, RTO? Как настроить поведение систем при отработке отказа?
Начнем с поведения системы при отработке отказа. План действий всех систем настраивается в разделе План восстановления. В нем мы можем указать практически любое необходимое нам поведение при восстановлении. Например, поднять VPN-канал с локальной сетью, запустить контроллер домена в Azure, потом запустить сервер 1С и т. д.
Минимальное время между репликами пока – 5 минут. Максимальное – 30 минут. Это время и есть наш RPO (Recovery Point Objective), или допустимая потеря данных.
Сервер после восстановления запускается 10 минут – это наш RTO (Recovery Time Objective), время на восстановление данных.
Что бы Azure понял, что наша инфраструктура ушла в отказ, и автоматически отработал его, необходимо настроить агента Operations Management Suite (OMS) и с помощью средств автоматизации запустить скрипт Runbook.
Для минимизации RPO мы использовали Azure Files – сервис репликации файлов с хранилищем Azure. В частности, настроили SQL Server на сохранение журналов транзакций в каталог, который синхронизировался с Azure Files, а после отработки отказа – выполнили восстановление журнала.
Стоимость
Стоимость репликации сервера 1С с общим объемом дисков в 2 ТБ составляет:
Ресурс |
Кол-во |
Цена |
Сумма |
Защищенный экземпляр Azure Site Recovery в Azure |
1 |
1 562,50 руб./мес. |
1 562,50 руб./мес. |
Хранилище BLOB-объектов тип «Стандартный», ГБ |
2048 |
2,81 руб./мес. |
5 760,00 руб./мес. |
Итог |
7 322,50 руб./мес. |
Стоит отметить, что в течение первого месяца (31 день) ASR предоставляется бесплатно.
После момента отработки отказа стоимость ресурсов составит:
Ресурс |
Кол-во |
Цена |
Сумма |
Виртуальная машина D4 v3 (4 ядра, 16 ГБ RAM) |
1 |
26,50 руб./час |
26,50 руб./час |
Хранилище управляемых дисков тип «Стандартный» 2048 ГБ |
1 |
5 120,00 руб./мес. |
5 120,00 руб./мес. |
Суммировать стоимости нельзя, так как временные промежутки разные. Вычислительные мощности в Azure считаются поминутно.
Частичным альтернативным решением может служить установка второго физического сервера и настройка репликации между серверами. Тогда потребуется покупка оборудования и программного обеспечения. Расчеты приведены в нашей предыдущей статье. Общая сумма затрат на один дополнительный сервер составит:
Наименование |
Кол-во |
Цена, руб. |
Сумма, руб. |
Сервер HPE ProLiant DL325 (16 ядер x 2,40 ГГц, 32 ГБ ОЗУ, 2 x 400 ГБ SSD, 2 x 300 ГБ SAS, 4 Гбит LAN), 3 года гарантии |
1 |
727 740,00 руб. |
727 740,00 руб. |
Лицензия Windows Server Standard 2024 |
2 |
55 121,00 руб. |
110 242,00 руб. |
Лицензия SQL Server Standard 2024 |
1 |
56 047,00 руб. |
56 047,00 руб. |
Итог |
894 029,00 руб. |
Стоит отметить, что такое решение менее выгодно для предприятия, так как требует изъятия из оборота компании крупной суммы, а также не является катастрофоустойчивым. Когда серверы рядом, это не защитит от пожара или потопа. И при использовании железа надо помнить про необходимость формирования на складе ЗИП, нагрузку на ИТ-персонал, электроэнергию и т. д.
Выводы
Azure Site Recovery подходит для резервирования локальной инфраструктуры, в частности 1С. Данное решение выгодно отличается низкой стоимостью. Простота реализации позволяет, не меняя существующую инфраструктуру, решить вопросы надежность и обеспечения катастрофоустойчивости 1С.
Отдельно стоит отметить, что внедрение ASR позволяет освободить предприятие от капитальных затрат на оборудование и программное обеспечение. И так как Site Recovery предоставляется в качестве сервиса, предприятие может планировать свои затраты.
Может быть полезным:
- https://info.microsoft.com/CE-AzureINFRA-CNTNT-FY18-05May-15-MicrosoftAzureplatform-MGC0002445_01Registration-ForminBody.html
- https://info.microsoft.com/CE-AzureINFRA-CNTNT-FY18-05May-20-DeploymentofEnterpriseontheMicrosoft-MGC0002460_01Registration-ForminBody.html
- https://info.microsoft.com/CE-AzureINFRA-CNTNT-FY18-05May-17-Deployment1CEnterpriseontheMicrosoftAzureplatform-MGC0002447_01Registration-ForminBody.html
- https://info.microsoft.com/CE-AzureINFRA-CNTNT-FY18-05May-21-EnterpriseontheMicrosoftAzureplatform-MGC0002461_01Registration-ForminBody.html
В обоих случаях, Ажур и второй сервер, забыли стоимость лицензии на сервер 1С. Пользовательские тоже могут понадобиться, особенно если они программные.
А зачем нужна вторая лицензия на Windows Server Standard 2018 для физического сервера?
И не совсем корректно сравнивать стоимость одной «Виртуальная машина D4 v3 (4 ядра, 16 ГБ RAM)» c «Сервер HPE ProLiant DL325 (16 ядер x 2,40 ГГц, 32 ГБ ОЗУ» — производительность будет явно не в пользу первой, хотя конечно явно лучше чем простой в работе.
Вероятность попадания метеорита в Северную Америку учитывается?
(2) Да, учитывается 🙂 Поэтому сервис предоставляется и посчитан из Западной Европы, резервирование которого автоматом идет в Северную Европу.
(1) Для работы 70 человек D4 v3 будет достаточно. Можно и больше — все равно платежи за мощность возникнут только в момент отработки отказа.
А лицензий windows Server 2 так как 1 лицензия закрывает 16 физических ядер, а в сервере их 32.
Относительно 1С сервера — его можно вынести на отдельный сервер / железный ключ и просто покинуть на активный сервер (раздавать с сервера на земле).
(4)
Для работы 70 человек можно и дектопную машинку поставить на случай ахтунга. Тоже будет достаточно ресурсов.
Позвольте, где здесь 32 ядра заявлено? В спецификации только 16 : «Сервер HPE ProLiant DL325 (16 ядер x 2,40 ГГц, 32 ГБ ОЗУ, 2 x 400 ГБ SSD, 2 x 300 ГБ SAS, 4 Гбит LAN), 3 года гарантии»
Отдельный сервер для лицензирования 1С видимо в план катастрофоустойчивости не входит? Железный ключ тоже не так просто прокинуть, да и опять же, где гарантии выживания железного ключа в катастрофе?
И катастрофоустойчивость это всё же не только выход из строя серверного оборудования, а так вполне годный вариант на случай поломки сервера.
А что по поводу стоимости SQL сервера в облаке?
Мне кажется, что Вы как-то странно расчитываете затраты на дополнительный сервер. Лицензии на win server, а также SQL server у Вас уже имеются т.к. вы уже имеете рабочую систему на одном сервере. Соответственно вы можете установить на резервную железку бесплатный win hyper-v сервер и реплицировать виртуальные машины. Таким образом, из Вашей таблицы остаётся только стоимость доп. железки, в качестве которой Вы можете использовать сервер с конфигурацией, аналогичной вм Azure т.е. 4 ядра и 16 Гб. Соответственно её стоимость будет существенно меньше, заявленной Вами.
Относительно катастроф остойчивости — какова вероятность наступления этого события и из какого локейшна и как будут работать пользователи в случае наступления этой самой катастрофы?
(6) Из правил лицензирования следует, что лицензии должны быть на все сервера. Мы же с Вами говорим про репликацию, а не бэкап.
А вот клиентские лицензии (CAL) мы как раз убрали из расчета.
И сам Hyper-V входит в состав ОС, которая стоит денег.
Под катастрофой моно подразумевать события, которые приведут к недоступности локального оборудования:
Потоп в серверной (такое было уже), изъятие оборудование органами (тоже было), авария на подстанции (тоже было), выход из строя материнской платы сервера (ну вы поняли 🙂 ) и тп. и тд. А работать надо.
(7)
Из правил лицензирования следует, что лицензии должны быть на все сервера. Мы же с Вами говорим про репликацию, а не бэкап
Полагаю, что Вы ошибаетесь.
https://social.technet.microsoft.com/Forums/ru-RU/678d3a8b-d527-4103-aebc-f7c20297656b/-?forum=licenseru
Ниже по ссылке рассмотрен аналогичный вопрос со ссылкой на FAQ MS:
И сам Hyper-V входит в состав ОС, которая стоит денег.
Я предлогаю для резервного сервера использовать Windows Hyper-V Server, который бесплатен.
Под катастрофой моно подразумевать события, которые приведут к недоступности локального оборудования:
В случае пожара или наводнения из строя также выйдет и сетевое оборудование и кабели, так, что облако здесь не сильно поможет, если только у Вас нет резервного офиса 🙂 Как вариант, Вы можете разместить резервное оборудование в отдельном от основного помещении. Аналогичная ситуация и с отключением эл. энергии.
Относительно органов — а почему Вы решили, что будет изят только один сервер?
поворчу малость
при наличии финансов многое можно решить. даже ума нинада %) можно позвать того, кто сделает все за деньги.
так что обычно делают из того, что есть в наличии
Есть пара сомнений в этом деле:
1. Мне кажется, или это не законно?
* 1с — база с персональными данными
* Она уходит за границу
2. Еще я не в курсе, может кто подскажет, эти образы виртуалок, они же не зашифрованы? Т.е. умея читать внутреннюю файловую систему образа, любой сможет получить доступ к базам
(9) Думаю, что 7 000 руб. не так много, что бы обеспечить резервирование. И даже не надо использовать то что есть, тем более когда этого нет.
(10) Незаконных моментов тут нет. Перс данные первично собираются и обрабатываются на территории РФ.
Формальное нарушение может возникнуть только на момент отказа, но если это зафиксировать в документах и регламентах — нарушения нет.
Доступа к образам нет, так как:
1. Все данные передаются в зашифрованном состоянии.
2. Хранятся данные только в зашифрованном состоянии.
(12) как это на момент отказа, бэкап-то в облаке всегда на территории «потенциального противника» 🙂
раз бэкап «там», то и персональные данные «там» хранятся. Не обрабатываются, но хранятся. Я не думаю, что Azure заключил соглашение со всем коллективом предприятия о хранении их персональных данных.
Я еще слышал о соглашении «на трансграничную передачу персональных данных сотрудника», вроде оно позволяет передавать перс.данные третьим лицам, но не уверен, что это можно делать «туда»
вот тут у меня пробел знаний, поэтому и спрашиваю. Ведь если что-то шифруется, где-то лежит ключ для дешефрации. Из увиденного я так понял что мы просто логинимся на сайте и скаиваем образы обратно. Ни про какие «токены» «ключи» и пр. рассказа не было. А раз мы просто логинимся, то образы на сервере «потенциального противника» лежат как есть.
(13) Относительно перс. данных — предлагаю обратиться к первоисточнику. Изучить его и разобрать.
Если подытожить — то закон не запрещает передачу перс. данных, а требует что бы первичные сбор, обработка и хранение осуществлялись на территории РФ. Ну а далее, при соблюдении внутренних регламентов, можно и трансграничную передачу осуществить.
Относительно Azure Site Recovery — это сервис по репликации виртуальных машин в облако. При желании, владелец подписки может скачать образ, но изначально сервис создан для обеспечения отказоустойчивости локальной или облачной инфраструктуры.
Есть конечно и отдельно Azure Online Backup — сервис по хранению резервных копий. При создании генерируется ключ шифрования, который храниться только у Вас. Он необходим для получения доступа к капу.
(8)
Может мы говорим о разном, но такой версии Windows Server нет. (https://www.microsoft.com/ru-ru/cloud-platform/windows-server-pricing)
Были ситуации. Даже если забирают все, сотрудники принесли ноутбуки из дома и продолжили работу.
Можно и кафе через дорогу использовать. Пожара у нас не было, но вот свет отключали на пару дней — работали кто из дома, кто из кафе.
Конечно вариант, но вопрос цены.
(5)
Можно. но не надежно.
(5)
Виноват, ошибся. Минус 55 тыс. из затрат на локальную инфраструктуру. Остается 839 тыс. Пока все равно больше, чем стоимость репликации.
(5)
Окей, используйте комплект резервных ПИН-кодов. Это просто потребует некоторых усилий при отказе.
(5)
ВМ с SQL Server на борту стоит 51,50 руб. в час.
Если у Вас SQL Server + Spftware Assurance, то можно действует преимущество гибридного использования, а следовательно не надо платить за SQL Server и тогда стоимость ВМ — 26,50 руб в час.
(18)Ок. Изначально поставляется 3 ключа. Первый используем для активации лицензии на рабочий сервер. Второй — в случае запуска резервного сервера в Ажуре. Третий — когда вернёмся на рабочий сервер. В любом случае это дополнительная ручная операция и дополнительное время на разворачивание рабочей конфигурации. Плюс дополнительный риск при повторении аварийной ситуации — запрос дополнительных ключей в 1С может занять достаточно много времени — и день и два, а то и больше. А уж если постоянно их теребить, то вообще могут отказать. Повод задуматься про кроилово, которое ведёт к попадалову.
В случае если нет возможности сделать свою нормальную серверную, чтоб не заливало, рисков ареста оборудования и отключения электроснабжения на продолжительные периоды имеет смысл задуматься над арендой выделенного сервера или размещении своего оборудования на площадке нормального дата-центра. По деньгам выйдет почти тоже самое что и свой сервер в мокрой серверной. А с учётом потерь от аварий может и дешевле. Для резервирования можно арендовать сервер на независимой площадке и держать там горячую копию баз — это опять же примерно те же деньги что и в Ажуре. Или уж совсем перейти на Ажур и надеяться что вас не оттелеграммят в неподходящий момент.
(18) Опять — двадцать пять.
Проблема с лицензиями обсуждает в другой ветке про Азур. Не может быть полной отказоустойчивости, без отказоустойчивости сервера лицензий 1С.
Вот если бы уважаемый Инфостарт спросил у 1С их планы по этому вопросу и озвучил бы их здесь, то это было бы реально полезно.
(15)
Можете скачать отсюда:https://www.microsoft.com/ru-ru/evalcenter/evaluate-hyper-v-server-2016
В pricing его действительно нет т.к. он бесплатен.
Роутеры, свичи, контроллеры домена etc. тоже принесли из дома :)?
Ну ОК 🙂
Ну так меня и смущает Ваша методика расчета локальной инфраструктуры для сравнения с облачной. Я собсно не против облаков и у них есть сври преимущества, однако сравнивать надо как-то более корректно что-ли, а то получается так, в облаке Вам достаточно 4х vCPU, а сравниваете Вы с сервером в 16.
В принципе, в приведенном Вами случае, на случай аварийной ситуации похоже подойдет обычный процессорный блок от desktop’а с 4х ядерным процом.
Соответственно по факту имеем 7K/мес — облако vs стоимость компьютера (ну или сервера начального уровня).
При стоимости процессорного блока 100К, он станет выгоднее ~через год.
(11)
кстати да, каждый месяц можно покупать новый винт
(24) Сервера же не только из винтов состоят.
(23)
у автора аргументация в пользу azure рассчитана на некомпетентного собеседника(передергивания и натяжки) , чем подрывает серьезное к себе отношение.
А вы по какому курсу стоимость Azure считали? Или случилось чудо и они стали стоимость в рублях фиксировать?
Статья больше напоминает рекламный пост от Microsoft , продвигающий Azure, чем реальная задача резервирования. Почему нет описания альтернатив Ажуру и практического опыта работы , замеров производительности, и т.д. ?
(28)Так это он и есть. Причем вторая статья по ажуру, от этого автора.
Все цифры из головы. Пусть надежность работы серверного железа 0.99999, а обычного десктопа 0.99. Т.е. вероятность отказа десктопа 1%, а сервера 0.001%. Закупаем три десктопа по стоимости 60 тысяч за системный блок (i5, 16 оперативки, 256 ssd) и настраиваем инкрементную репликацию баз данных. Вероятность одновременного отказа всех трех (конечно при условии что они не стоят рядом друг с другом и запитаны от одной розетки) 0.01#k8SjZc9Dxk3, т.е. 0.0001%. Т.е. в 10 раз надежнее. На сколько меньше затраты по железу — найдите стоимость сопоставимого сервера и отнимите. Где ошибка в рассуждениях?))
Как можно было сравнить hyper-v и aruze?
Автор рассматривает первый вариант отказоустойчивости sql — hyper-v??? Побойтесь бога.
Или sql вообще не рассматривается, а только 1с? Хотя сути это не меняет.
В чем усмотрели отказоустойчивость в кластеризации hyperv?
А понял, что хотелось просто по облако написать. Но сравнение взято не верно.
смотрю Майкрософт агрессивно впаривает
у них там сменились сотрудники, и новые сотрудники не заморачиваются фактами, это впринципе новый тренд — трындеть не отвечая за свои слова
по статье автору (0)
что вам мешает бэкапить логи и кидать их в другой город да хоть на обычный комп самый дешевый, вот и вся катастрофоустойчивость
(32)
по статье автору (0)
что вам мешает бэкапить логи и кидать их в другой город да хоть на обычный комп самый дешевый, вот и вся катастрофоустойчивость
Купить место в облаке и бекапить туда 1С. Я так делаю давно. Надежнее чем локальные копии, правда и локальные копии тоже хранятся.
(33) а что без облака ни как? Обязательно надо отдавать бэкап в чужой сервер куда у вас нет быстрого доступа? И как вы измеряете надежность «облака»?
(33)Бэкапить в «черную дыру», не имея к ней физического доступа — такое себе занятие.
(34) по отказам. за 5 лет на одном нашем облаке не было потеряно ни одного файла. Облако нужно на тот случай, если локальные ресурсы выведены из строя. Например утащены обепом.
(35) Когда к вам придут люди с автоматами и начнут выносить технику, вы спасибо скажите за то, что к вашем бекапам нет физического доступа.
(37)Так что мешает держать свой NAS, находящийся в другом месте территориально, если уж есть поводы для визитов ОБЭПа?
(38)
Это зависит от размера компании. Если есть ресурсы, можно поставить сервер в датацентре и там держать бекапы. У кого денег не так много, бекапят на локальный сервер (nas) и в облако. Понятно что крупная компания построит свой датацентр.
Что касается поводов. То достаточно одного заявления и небольшой суммы. Приходят, показывают бумагу — «запрос сведений». Вы подписываете. Ваш офис — объявляют местом преступления и проводят обыск тут же. Изымают документы и технику.
Потом вас просят подписать перечень изъятого… вы подписываете.
Потом вы жалуетесь. А вам отвечают, что вы добровольно все отдали. Как будто, можно было отдать не добровольно…
(36) а какая разница утащит обеп или фбр? или думаете на заграничном сервере медом намазано? или где гарантия что ваша организация в своих целях не использует ситуацию
много банков вам свои данные доверило?
на внешних серверах есть смысл хранить данные, которые не представляют коммерческой ценности, метрики заббикса например
(39) спекулировать на «страхах» тот еще бизнес
мы вот небольшая компания, но резервный сервер в другом городе на линухе организовать осилили, ни каких космических сумм не надо
Думаю, те, кто перешел дорогу фбр, местный обеп пошлет в пешее путешествие. Не думаю, что обеп сможет придти с такой бумажкой в структуру к-нить условного «сбербанка» и попробует забрать сервера.
Необязательно использовать облако забугорного поставщика. Можно и отечественное. Кадры в обепе, не такие продвинутые, что бы смочь изъять оборудование, разобраться в течении часов, выбить решение суда о доступе к облаку, получить туда доступ и забрать файлы =))
На все это потребуется время.
Про банки — это отдельный разговор. Там просто так обеп резвится не будет. Все же они могут построить свой датацентр, обвязать его договорами и не мучатся.
«на внешних серверах есть смысл хранить данные, которые не представляют коммерческой ценности, метрики заббикса например»
Это понятно. Бекапы шифруются перед передачей. И не zip-rar понятно.