Операционная система устанавливается в среде виртуальной машины, такой как VMWare или KVM. В качестве системного раздела ОС используется общий сетевой том диска (например, диск iSCSI). В этой ОС идет интенсивный трафик. Что произойдет, если к тому совместно используемому диску временно невозможно получить доступ в течение двух или трех минут (из-за проблем с сетью или по другим причинам), а по истечении этого короткого периода он снова будет в сети? Произойдет ли сбой ОС или она продолжит работать без повреждения данных?
Я тестировал свой случай с гостевой ОС Linux. В период отсутствия доступа рабочий стол Linux зависает, и я не могу им управлять. Но когда к системному тому снова можно получить доступ, я снова могу использовать рабочий стол и обнаруживать, что предыдущие задачи продолжают выполняться.
Хотя мой тест кажется успешным, я не могу быть уверен, что он всегда в порядке. Я знаю, что ОС будет повторять операции ввода-вывода, поэтому, возможно, не имеет значения, если диск не возвращает операции ввода-вывода в течение короткого периода. Но ОС также использует раздел подкачки для подкачки некоторых страниц в памяти. Если операции подкачки приостановлены из-за диска, есть ли серьезные последствия?
Тайм-аут по умолчанию для scsi-дисков составляет 30 секунд, но вы можете изменить его, изменив / sys / block / disk / device / timeout, например, используя echo 180> / sys / block / disk / sda / timeout, чтобы увеличить время ожидания до 180 секунд. .
Я предполагаю, что это будет сильно зависеть от уровня виртуализации. FWIW, я только что протестировал это с помощью VirtualBox, и он просто завис, что для всех целей также может быть сбоем. У меня нет других систем для тестирования, и я не верю, что это поведение будет постоянным. Я подозреваю, что это будет немного зависеть от того, что на самом деле делает ОС в момент разрыва соединения.
Если вы потеряете диск на 2-3 секунды, вы наверное будет в порядке, и ОС продолжит работу после того, как снова станет доступной. Хотя в бревнах будет стонать и громко стонать.
Если вы потеряете диск на несколько минут, ОС может, а может и нет, Kernel Panic / BSOD, но если вам действительно не повезет, вы потеряете данные и систему. ВОЛЯ стать очень нестабильным.
Да, подсистема ввода-вывода попытается повторить попытку ... но она не будет повторять попытку в течение нескольких минут.
Если я правильно понимаю, системный раздел гостевой ОС является локальным с точки зрения ОС, а удаленный только для VMWare?
Не зная наверняка, мой опыт работы с VMWare показывает, что на это время виртуальная машина скорее остановится. На самом деле у меня была проблема с VMWare ESXi, когда хранилище (содержащее все виртуальные машины, и оно было локальным!) Было заполнено при увеличении размера расширяемого раздела. Все виртуальные машины были приостановлены. Мне пришлось удалить снимок, чтобы освободить место, хотя я не уверен, продолжали ли они работать сразу после этого (или после перезагрузки). Но не был критичным сервером, а я всего лишь разработчик, а не системный администратор :)
На самом деле это довольно сложный вопрос, и ответ зависит от конфигурации вашего хоста. Прежде всего, уровень iSCSI имеет собственные периоды ожидания и повторные попытки. То же самое касается device-mapper-multipath, который управляет блочными устройствами, и выше у вас есть уровень диска QEMU и драйвер контроллера диска в гостевой ОС. Чтобы не вдаваться в подробности, если вы планируете использовать нестабильное хранилище, гораздо безопаснее свести риски к минимуму. Этого можно добиться, отключив функцию кэширования диска QEMU ( cache=none в строке cmd) и используя werror=stop чтобы гость приостанавливал работу всякий раз, когда обнаруживает ошибку ввода-вывода, вместо того, чтобы пытаться продвигать этот ввод-вывод бесконечно. Если вы их не используете, с нестабильным хранилищем вы рискуете повредить изображение и потерять данные, хотя в некоторых случаях, если гостевая ОС обнаруживает ошибку ввода-вывода (например, если вы используете распространение), она может просто перемонтировать ее FS в r / o режим.
В любом случае, как правило, лучше избегать узких мест при доступе к диску, особенно когда задействованы виртуальные машины. Множественные пути и отдельные сети только для трафика iSCSI являются обычными средствами достижения этого.
Это зависит от многих настроек. ОС предназначена для повторных попыток ввода-вывода в течение некоторого времени. Продолжительность зависит от ОС и настроек ее подсистемы ввода-вывода и всех нижележащих уровней.
Например, рассмотрим виртуальную машину Linux, работающую на VMware ESXi. Виртуальная машина Linux думает, что работает на SCSI-диске, который на самом деле является файлом VMDK в файловой системе VMFS, управляемой VMware. Файловая система VMFS фактически находится в сети на iSCSI LUN в SAN. Множество слоев, каждый со своими настройками и таймаутами. В этом случае вам нужно проверить таймауты как на инициаторе iSCSI VMware, так и на подсистеме SCSI Linux.
В такой многоуровневой системе разумно увеличить таймауты по умолчанию, поскольку есть большая вероятность того, что что-то временно выйдет из строя. На самом деле VMware сама решает некоторые из этих проблем. Насколько мне известно, инициатор iSCSI программного обеспечения VMware имеет достаточно большие таймауты. Таймауты по умолчанию в Linux немного короткие:
$ cat /sys/block/sda/device/timeout
30
После установки VMware-tools на виртуальной машине время ожидания виртуальных дисков повышается до более безопасного значения - 180 секунд. Я не уверен, какое значение он устанавливает для виртуальных машин Windows.
Однако более длительный тайм-аут не является гарантией. Гостевая ОС с высокой активностью дискового ввода-вывода может быть не в состоянии поддерживать устойчивые запросы чтения и / или записи в течение значения тайм-аута. Гости Windows могут зависнуть или BSOD. Гости Linux могут перейти на свои корневые тома только для чтения, что требует перезагрузки для исправления.
Хотя ОС может пережить прерывание дискового ввода-вывода, приложения, работающие на платформе ОС, не могут. Сами приложения реализуют значения тайм-аута ответа, которые, вероятно, будут жестко запрограммированы и не могут быть настроены администратором платформы или виртуализации в самом приложении.
Личный опыт: однажды я обновил прошивку SAN и перезагрузил SAN. Эта перезагрузка достаточно быстрая, чтобы уложиться в таймауты как VMware ESXi, так и моих виртуальных машин Linux и Windows. Обычно все виртуальные машины работали нормально. Однако на этот раз задержка не понравилась одной виртуальной машине, и она сильно вылетела. Никакого ответа. Настолько сильно, что мне не удалось убить виртуальную машину, и мне пришлось перезагрузить весь хост VMware.