Дмитрий Чистяков, для начала склонировать посекторно диски с помощью любых программ позволяющих сделать клон. Потом одновременно можно идти двумя путями. Импортнуть рейд на сервере и использовать на клонах ПО восстановления (пересобрать ими рейд). Можно даже еще клон клона сделать для верности. (образы).
Странно что сколь-нибудь важная информация хранилась на R0.
Еще вариант - поставить ftp, как указал ниже zer0Hexen. Filezilla server или вроде того. Для пользователей эта папка будет smb, для сканера доступ по ftp.
Обычно есть в управлении рейдом - import. И можно попытаться импортировать конфигурацию дисков. Но как правильно написал Zettabyte - лучше попробовать склонировать имеющиеся диски и попробовать восстановить. Если конечно там есть ценная информация. Если нет - можно просто попробовать импортнуть, посмотреть что будет
1. КЛАСТЕР СХД в режиме что active/passive, что active/active не предназначен для таких решений. Его задача - иметь резервирование на уровне СХД. При выходе из строя одного из контроллеров - передаем другому флаг и работаем с ним. То есть passive в этот момент получается Master и при ближайшей возможности захочет передать свои данные на вторую СХД, которая тоже считает себя master. Как-то так всегда кластеризованную СХД представлял.
2. Вот репликацию на уровне СХД уже можно рассмотреть как вариант. Где именно master/slave и асинхронная репликация по запросу. Она в данном случае может позволить вам экономию на времени создания/восстановления бэкапа. Скажем, 50% времени.
3. Существует еще вариант снепшотов и их эксплуатации в рамках одной СХД, не важно - кластеризованной или нет. Сам не использовал, но, насколько я понимаю, в части СХД можно создавать снимки данных и использовать их для последующего снятия резервных копий. Это распространенный функционал. Кроме того, в наиболее гибких должна быть возможность работать со снимками, то есть создаем снимок и здесь же, на этой же СХД имеем основную ветку данных (дополнение к снимку в продуктовом контуре) и дополнительную(ые) ветку(и) где идет работа с как бы репликой на основе снимка. Где я это встречал я уже не помню. Кажется было и на хабре что-то в материалах по тестировщикам, где это наиболее востребовано. Ну и вендоры СХД должны рассказывать сами как и что они умеют.
4. Если эти некие накопленные данные лежат в СУБД, то почему не использовать штатный механизм репликации самой СУБД? Практически все они умеют сами реплицировать данные, уж асинхронно - точно.
Новое железо работает на других частотах, с шинами большей пропускной способности между всеми компонентами. Разница в возрасте между платформами в этом случае достаточно велика. Это прежде всего.
Далее - каждая из перечисленных железок в клубе лучше. Браузер использует все из них. Видео для аппаратного рендеринга страниц, память жрут все браузеры как не в себя, да и частота самой памяти в данном случае может оказывать влияние т.к. слишком большой разрыв. ЦПУ тоже берет на себя часть работ с браузером и передачей данных по сети.
Скрин со скоростями интернета не показатель, это не говорит ничего о самом компе, только о скорости подключения его к интернету.
Даже в теории чтобы этого добиться нужно настраивать в том или ином виде синхронизацию данных о пользователях/некую федеративную связь. Если доступ нужен не с s2, а непосредственно с ПК, то почему на ПК не прописать тот же сетевой диск с подключением от S3\IvanovS3 ?
Akina, решение не требует синхронизации паролей, пользователи S2 могут менять свои пароли как пожелают. Вот на сервере S3 им пароли менять не следует, но они могут этих паролей и не знать.
На всякий случай уточняю механизм. Есть пользователь Ivanov (S2), ему нужно в папку на сервере S3. Создаем пользователя IvanovS3 (на сервере S3). На сервере S2 находясь под учеткой Ivanov подключаем сетевой диск, в настройках подключения пишем "использовать другую учетную запись" вводим данные S3\IVanovS3 и эту запись сохраняем. Сетевой диск теперь доступен пользователю. Он может менять пароль на S2, его учетка никак не повлияет на другую учетку на S3. Чем не решение?
1 - имеет смысл делать raid если мы хотим добиться безостановочной работы сервера. Один диск может сдохнуть, но сервер продолжит работать пока работает второй. Если админ уехал загорать, сервер его дождется, пользователи ничего не заметят. В случае с ssd раньше даже "прожигали" предварительно один из дисков чтобы в случае отвала по окончанию ресурса одинаковые диски не отвалились единовременно.
2 - вполне надежен. Речь ведь не про "динамические диски" из утилиты "управление дисками", а про консоль "диспетчер серверов"? Для nvme вообще мало аппаратных решений, обычно используют программные, т.к. получается быстрее. У интела, кстати, были какие-то vroc с отдельными лицензиями, но это вроде только на серверных чипсетах.
3. - есть просадка по скорости. Вычислить заранее не получается. Бывает 5-10%, но бывает и больше. Почему - не знаю. Зависит от дисков, ОС, мат платы, ЦПУ. Да, кстати, немалая часть ресурсов ЦПУ задействуется под работу с дисками. У вас юзеров всего 25-30, не должно быть огромной нагрузки.
Все диски желательно брать серверного сегмента. Тот же sata можно kingston dc серии, с кешем на борту и защитой по питанию, он не дорогой и поставляется официально. А вот m2 nvme с кешем и защитой не припомню, только u2.
Учтите что сам сервер 1С очень любит писать данные на системный диск (профиль пользователя 1cusr), он создает там всякие темпы и журналы. В зависимости от конфигурации 1С это может быть узким местом, а не СУБД.
Восстановление на практически любой момент времени предусмотрено в самой СУБД, там бэкапы можно раз в 5 минут снимать.
Дмитрий, если у человека изначально нет задачи поднимать линуксовые сервисы (в задаче явно обозначена винда), то зачем дополнительные сложности с проксмоксом? Бэкапы, снепшоты, миграции прекрасно решаются в hyper-v. Если уж очень хочется виртуализации. А лицензии и на вирт машине слетают только так при любом чихе. Надо диск раздвинуть - привет лицензия.
Подключение сетевого диска с сохранением имени пользователя решает задачу. Про постоянное - не постоянное в задаче не было ничего. Имя пользователя сервер должен знать, то есть пользователь у него должен присутствовать как локальный.
tictac17, да, все верно. Для SSD нет смысла задействовать память контроллера для кеширования. Быстрее сразу писать на диск (особенно если у диска есть своя память и если есть свое резервное питания для кеша)
Начните с тех требований под свою планируемую нагрузку. От требований будет зависеть решение по рейдам. Ибо R60 это потеря порядка 20% емкости и скорость записи примерно x2. А с R10 будет потеря емкости 50%, но скорость записи x9.
Плюс в некоторых конфигурациях вы можете использовать SSD tiering или кеширование. Это если диски серьезные. Диски которые указали 6 и 20 это делим между серверами или это в каждом по столько? Рейд контроллер аппаратный или HBA? Диски SAS или NL SAS? Емкость SAS дисков? (если более 10 тб то ребилд может быть ооочень долгим)
Поймите сколько и каких данных вы планируете хранить, какие скорости, резервирование вам требуются, уже потом будет понятно как диски разбивать.
Я бы выводил инфраструктуру отдельно, ВМ отдельно.
То есть вариант 2. Таким образом мы не пускаем ВМ (к которым имеют доступ юзеры) в инфраструктуру (сети SAN).
Из плюсов - все плюсы виртуализации. Понятное и прозрачное создание бэкапов ВМ, миграция ВМ на другие хранилки и сервера, универсальность (если у вас в парке есть другие ВМ, то все подходы аналогичны).
Из минусов - просадка по скоростям. Любая виртуализация этим страдает, но всех это устраивает. Лучше заранее провести тестирование скоростей с хоста и из ВМ, чтобы понять насколько проседаем.
В новых материнках на новых платформах не всегда получается включить CSM. Ты его включаешь, перезагружаешься, а он исчезает. Может помочь добавление внешней видеокарты или отключение одного из pci устройств.
Вам нужно для начала нажать TAB - чтобы видеть что там при инициализации происходит. На экране про это написано. Ну или в BIOS найти пункт который скрывает от вас происходящее за красивым логотипом.
Когда будет показывать инициализацию, там и CTRL+A будет приглашение от контроллера.
А если ОС установлена, то можно утилитки от вендора скачать и из-под ОС все смотреть. Там более информативно.
Странно что сколь-нибудь важная информация хранилась на R0.