Пример возникновения подобной картины.
ВМ пытается что-то записать на диск, часть данных записалась, часть в кеше.
В это время отключается ВМ. То есть жесткое отключение.
С точки зрения хостовой машины все ок. У нее своя файловая система, где все стабильно. Что там недописалось в файлик VHDX ей неизвестно.
Потом включаем ВМ и получаем ошибки на диске.
Похожая картина будет и при внезапном отключении хоста.
Рекомендация - пореже отключать питание ВМ и хоста. Ну и кеширование где можно поотключать. Там где оно батарейками не поддерживается.
d-stream, я вовсе не утверждаю что система должна быть завязана на HA или другую систему УД. Тем более на облако. Но установка тупого оборудования явно противоречит поставленной задаче, железобетонное тупое оборудование потом придется скорее всего заменить, это как минимум удвоит расходы.
И даже если с УД что-то пошло не так, система должна быть спроектирована так чтобы иметь возможность ручного управления, и не должна убивать все вокруг. Полы не закипят, как ты их не проси, узел подмеса должен быть спроектирован так чтобы подача не оказалась выше требуемой температуры.
Выйти из строя железобетонное оборудование тоже может. Контроллер сервоприводов буквально пару недель назад у товарища отправился в ремонт. Года два простоял. Ничего, как-то без него можно, просто неудобно.
VoidVolker, в принципе можно. Что-то такое можно поставить с реле. Но с калибровкой придется повозиться. Собственно дилер акары такое предлагает в качестве решения.
Просто у штоковых сервоприводов есть возможность регулировки степени открытия. А у некоторых еще и возможность привязки к внешнему датчику температуры. Тогда вообще автономная система получается. Датчик в комнату закинули, сервопривод смонтировали и все работает.
у вас на datastore2 по мнению veeam слишком мало свободного пространства в процентном соотношении. Виам считает что если во время бэкапа что-то будет писать в диск ВМ, то 160 гб очень быстро закончатся и риск не стоит свеч.
Если диски sata, просто подключите выделенный для ОС диск проводом к SATA контроллеру на мат плате.
Остальные варианты возможны только после того как вы полностью опишите модель контроллера, дисков, сервера. В некоторых контроллерах есть возможность часть дисков перевести в режим jbod (то есть предоставить доступ к ним напрямую), в некоторых нет.
Ну очень странная история. У Алисы есть возможность запомнить голос ребенка, она должна знать по учетке что это детский аккаунт. И дальше должна включать что положено. А какая, кстати колонка? Цвет, модель...
Node red - несколько менее монструозен чем HA. Есть возможность кодить, визуально простые вещи собирать.
Насчет плавного включения, у некоторых ламп это штатный функционал. Задаем время реакции и переключение становится плавным. Лучше использовать его.
Включение через отправку сотен сигналов установления яркости нагружает сеть лишними пакетами.
Базу 1с - не базовую, обычную. Просто не уверен что можно купить апгрейд с базовой. И будет у вас одна лицензия на одного пользователя. Порядка 20 тр.
Лицензию на одно рабочее место отдельно. 8500 р.
И будет у вас две лицензии (вероятно пин коды) которые можно установить на разных компах и пустить туда бухов (только не РДП). Или одну поставить на вирт машину на том же ноутбуке. Один работает на ноуте, второй на вирт машине (но где-то комп у него должен все равно быть, поэтому нафиг вирт машину.)
При этом важно учесть ежегодные платежи за подписку ИТС. т.к. база сразу не базовая у вас и ежегодно порядка 20 т.р. будете платить за обновления конфигурации.
Все цены в открытом доступе https://v8.1c.ru/price/
Лицензия на одного юзера - 4601546116697. Еще раз уточню момент - не RDP! Для rdp подходят сетевые лицензии (от 5 юзеров) и там тоже много тонкостей сейчас из-за программных ключей. Даже не знаю локальный можно ли впихнуть в сессию пользователя.
Насчет тормозов - до 5 юзеров обычно нет разницы в скорости работы между файловыми и серверными вариантами в случае RDP сервера. В случае обычной файловой базы с доступом к папке с других ПК разница есть, но при нормальной сети незначительная. 2-4 ПК на гигабитке норм.
hint000, параметры тестирования на рандоме и линейном - разные. 4k и 1m. От этого мы можем получать различные результаты. Ну и IOPS нам вроде не показывают.
Дмитрий Чистяков, для начала склонировать посекторно диски с помощью любых программ позволяющих сделать клон. Потом одновременно можно идти двумя путями. Импортнуть рейд на сервере и использовать на клонах ПО восстановления (пересобрать ими рейд). Можно даже еще клон клона сделать для верности. (образы).
Странно что сколь-нибудь важная информация хранилась на 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. Чем не решение?
ВМ пытается что-то записать на диск, часть данных записалась, часть в кеше.
В это время отключается ВМ. То есть жесткое отключение.
С точки зрения хостовой машины все ок. У нее своя файловая система, где все стабильно. Что там недописалось в файлик VHDX ей неизвестно.
Потом включаем ВМ и получаем ошибки на диске.
Похожая картина будет и при внезапном отключении хоста.
Рекомендация - пореже отключать питание ВМ и хоста. Ну и кеширование где можно поотключать. Там где оно батарейками не поддерживается.