1. Опускать рубильник не обязательно. Даже при наличии stretch кластера (но при определенной настройке). 2. На стандарте поднимете, только на 2019, но есть ограничение в одну Storage группу и её объем (если не ошибаюсь 1 или 2ТБ) 3. Volume должны быть не только одинаковые по размеру (байт в байт), но и иметь одинаковые физический и логические размеры сектора. Это реально может вызвать проблему при создании реплики между старыми-новыми физическими серверами (с схд или локал дисками), либо как в моём случае, при выполнении миграции с hyper-v на vSphere даже на виртуальных машинах. communities.vmware.com/thread/601465, решить так и не удалось.
@@IlyaMCT с двумя никак, только стретч кластер. Плюс, насколько помню, реплика при этом должна быть синхронной ну и само собой виртуализация сети между площадками.
Fullydownable п.3 vSphere хреново дружит с physical и logical секторами. Там много костылей для совместимости в рамках инфраструктуры VMware.😉 Почему бы не смигрировать ВМ напрямую, если у вас сервис кластеризован?
@@umnique884 Этот вариант не рассматривали, начальный и целевой кластер были на разных площадках. Но даже миграция на "живую" не решила бы проблем гостевых дисков, которые в VMware и Hyper-V имеют разный размер сектора). PS (Они подключены именно как виртуальные диски, не iscsi и не fc)
Здравствуйте Илья. Регулярно смотрю ваши видео. Вы уже касались в них вопросов работы с облачными сервисами, не могли бы вы сделать больше видео на эту тему. В идеале хотелось бы видеть полноценный и всесторонний взгляд на CI/CD с точки зрения классического СисАдмина, а так-же на обеспечивающие их технические средства( docker и альтернативы, k8s и альтернативы, ведущие облачные провайдеры - AWS, Azure, Google... и альтернативы )
Добрый день. Спасибо, что смотрите. Прям по всем обласным провам я пройтись не могу, т.к не имею опыта с тем же AWS. Тема настолько огромна, что надо заходить с какого то конца. Сейчас я делаю курс по AzureAD. Но контект по облакам в ближайшее время будет.
Если это как-то увязать HA, то, думаю, было бы круто. Кстати, а что мешает в DFS указать сразу 2 конечные точки? Ведь учитывая принудительную недоступность второго ресурса, клиент будет выбирать очевидное - первый. И обратное, при недоступности первого - второй начнет работать. Единственное оснастка DFS не дает по-моему добавить новую точку подключения, если она недоступна... Но схема то должна работать.
👍 спасибо! Интересно ещё, в каких случаях команда в пошике не отработает, реплика не поднимется и все будет очень плохо. Но, видимо, это уже другая история)))
Интересно где бы ещё применить это, так то репликация на уровне приложения всегда лучше, dfs replication, sql always on, exchange dag, и в случае с dfs, там пользователи автоматически переключаются, а тут ручками надо делать. С тем же успехом можно бэкапы между сайтами крест накрест делать и из них поднимать. В том же veeam есть instance recovery, когда прямо с бэкапного хранилища ВМ запускает.
Репликация на уровне приложения работает с данными приложения. Репликация на уровне файловой системы работает на уровне файловой системы. Работая с репликой на уровне блоков, вы можете использовать любые приложения поверх. Вы же не думаете о рейдах, размещая на них данные программ. Это просто ещё один уровень абстракции. Надеюсь, внятно объяснил.
@@Fullydownable Это понятно, но для маленькой организации это не нужно, да и дорого, а большая будет реплицировать LUNы средствами массивов (с использованием плагинов чтобы была консистентность) или использовать средства приложений. Некоторые базы данных после блочной репликации могут не запуститься. Придется дополнительное время тратить чтобы привести в консистентное состояние.
TheAnahaym в Windows Server 2019 DFSR на месте, если говорить о Sysvol. 😉 Как верно заметили в другом комментарии - это разные уровни. А значит, разные границы применимости.
никуда не убирали. Поменялось лицензирование. Хотя и раньше вы не имели права его запускать не имея Software Assurance. Но этого никто не знал и дружно его использовали. Рекомендую прочитать docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel и это docs.microsoft.com/ru-ru/windows-server/get-started/getting-started-with-nano-server
Fullydownable хмм первую ссылку не видел, но ведь по факту получается в дистрибутиве win 2019 nano server-a нет... а получается, то что просто nano server с редакции win2016 просто будет получать обновления.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
1. Опускать рубильник не обязательно. Даже при наличии stretch кластера (но при определенной настройке).
2. На стандарте поднимете, только на 2019, но есть ограничение в одну Storage группу и её объем (если не ошибаюсь 1 или 2ТБ)
3. Volume должны быть не только одинаковые по размеру (байт в байт), но и иметь одинаковые физический и логические размеры сектора. Это реально может вызвать проблему при создании реплики между старыми-новыми физическими серверами (с схд или локал дисками), либо как в моём случае, при выполнении миграции с hyper-v на vSphere даже на виртуальных машинах. communities.vmware.com/thread/601465, решить так и не удалось.
А по поводу первого пункта, как там автоматизировать с двумя серверами?
@@IlyaMCT с двумя никак, только стретч кластер. Плюс, насколько помню, реплика при этом должна быть синхронной ну и само собой виртуализация сети между площадками.
Fullydownable п.3 vSphere хреново дружит с physical и logical секторами. Там много костылей для совместимости в рамках инфраструктуры VMware.😉
Почему бы не смигрировать ВМ напрямую, если у вас сервис кластеризован?
@@umnique884 Этот вариант не рассматривали, начальный и целевой кластер были на разных площадках. Но даже миграция на "живую" не решила бы проблем гостевых дисков, которые в VMware и Hyper-V имеют разный размер сектора). PS (Они подключены именно как виртуальные диски, не iscsi и не fc)
@@IlyaMCT @ИТ-Видео SCOM + Powershell scripts для автоматизации
Здравствуйте Илья.
Регулярно смотрю ваши видео. Вы уже касались в них вопросов работы с облачными сервисами, не могли бы вы сделать больше видео на эту тему. В идеале хотелось бы видеть полноценный и всесторонний взгляд на CI/CD с точки зрения классического СисАдмина, а так-же на обеспечивающие их технические средства( docker и альтернативы, k8s и альтернативы, ведущие облачные провайдеры - AWS, Azure, Google... и альтернативы )
Добрый день. Спасибо, что смотрите. Прям по всем обласным провам я пройтись не могу, т.к не имею опыта с тем же AWS. Тема настолько огромна, что надо заходить с какого то конца. Сейчас я делаю курс по AzureAD. Но контект по облакам в ближайшее время будет.
Если это как-то увязать HA, то, думаю, было бы круто. Кстати, а что мешает в DFS указать сразу 2 конечные точки? Ведь учитывая принудительную недоступность второго ресурса, клиент будет выбирать очевидное - первый. И обратное, при недоступности первого - второй начнет работать. Единственное оснастка DFS не дает по-моему добавить новую точку подключения, если она недоступна... Но схема то должна работать.
А если поднимем fs02 репликация в обратную сторону сработает? Все изменения, которые были на fs03 реплицируются на fs02 после "условного" включения?
А в линукс есть rsync и ему все равно открыт файл и какой длинны имя файла. Копирует все.
👍 спасибо! Интересно ещё, в каких случаях команда в пошике не отработает, реплика не поднимется и все будет очень плохо. Но, видимо, это уже другая история)))
Что за виртуалка использовалась в видео?
Обычный стенд на hyperv
Забавно. А логи всё равно никому не нужны (ну как файлики). Зачем не какой-ндь блочный доступ к разделу логов? Зачем ньютехнолоджиФС?
Интересно где бы ещё применить это, так то репликация на уровне приложения всегда лучше, dfs replication, sql always on, exchange dag, и в случае с dfs, там пользователи автоматически переключаются, а тут ручками надо делать. С тем же успехом можно бэкапы между сайтами крест накрест делать и из них поднимать. В том же veeam есть instance recovery, когда прямо с бэкапного хранилища ВМ запускает.
Ну если вы заранее уверены, что условный dfsr лучше, то наверно нигде)
Репликация на уровне приложения работает с данными приложения. Репликация на уровне файловой системы работает на уровне файловой системы. Работая с репликой на уровне блоков, вы можете использовать любые приложения поверх. Вы же не думаете о рейдах, размещая на них данные программ. Это просто ещё один уровень абстракции. Надеюсь, внятно объяснил.
@@Fullydownable Это понятно, но для маленькой организации это не нужно, да и дорого, а большая будет реплицировать LUNы средствами массивов (с использованием плагинов чтобы была консистентность) или использовать средства приложений. Некоторые базы данных после блочной репликации могут не запуститься. Придется дополнительное время тратить чтобы привести в консистентное состояние.
Вопрос в другом, если DFSR не будет, а Storage Replica только в Datacenter, как быть с Active Directory? Или я что-то путаю?
Там ниже подсказали, что в std 2019 есть кастрированная версия. А ад причем?
@@IlyaMCT ну как причём, а SYSVOL чем реплицируется, не DFSR, от которой отказваются? Или DFSR и DFS Replication это разные вещи?
@@TheAnahaym вообще разные сервисы построенные на одной исходной технологии. На репликацию sysvol storage replica не претендует.
@@IlyaMCT ну тогда я спок ) спасибо
TheAnahaym в Windows Server 2019 DFSR на месте, если говорить о Sysvol. 😉
Как верно заметили в другом комментарии - это разные уровни. А значит, разные границы применимости.
это же тот же самый DRBD ru.wikipedia.org/wiki/DRBD ? Нафига такие бабки платить...
Спасибо :-) посмотрим :-)
и снова не для лицензии стандарт. спасибо, майкрософт 😐
в 2019 сервере, Storage Replica добавлена в стандарт...
Nano server же убили совсем, в 2019 его нету...неудачная попытка вышло, оставили только server core
Я чет проспал этот момент)
никуда не убирали. Поменялось лицензирование. Хотя и раньше вы не имели права его запускать не имея Software Assurance. Но этого никто не знал и дружно его использовали. Рекомендую прочитать docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel
и это docs.microsoft.com/ru-ru/windows-server/get-started/getting-started-with-nano-server
Fullydownable хмм первую ссылку не видел, но ведь по факту получается в дистрибутиве win 2019 nano server-a нет... а получается, то что просто nano server с редакции win2016 просто будет получать обновления.
@@PiligriM2K потому что нано сервер для контейнеров давно уже и на докерхабе регулярно новые билды.
Anton Masyan спс
В общем это некий DRBD, только от microsoft )
По сути да.
Познавательно .
коммент
Самая бяка во всех этих сайтрековери - настройка нижней части айсберга кнопки/рубильника. А уж про регулярные тесты этого дела, как часть дрп.....
Любые Site Resilience требуют наличия команды мужей в ИТ-отделе. Иначе весь этот Resilience до первого крэша.
сырая технология
Другие технологии MS уже давно не выпускает)
@@IlyaMCT Я пока лучше с Veeam подружу))) Но пусть пилят, может что годное получится