Что такое разумное время обработки отказа устройства хранения данных, когда большая часть ОС (VM) может терпеть?
У меня есть узел GlusterFS 2 2 установки копии. Я планирую использовать его в качестве хранилища экземпляра OpenStack, в котором хранится образ диска VM.
От моих тестов, если узел GlusterFS, который гипервизор в настоящее время монтирует на сбоях, (использующий настройки GlusterFS по умолчанию) требуется приблизительно 45 секунд для соединения с тайм-аутом и glusterfs клиентом, заменяет к другому узлу. Во время этого 45 секунд операции IO зависнут с точки зрения VM, которая означает, что диск становится безразличным.
Я знаю для Linux, если диск становится безразличным, через какое-то время (я не уверен, сколько времени) ядро повторно смонтирует файловую систему как только для чтения.
Я могу также понизить значение объема GlusterFS network.ping-timeout, который уменьшит время обработки отказа.
Мой вопрос, насколько я должен установить это значение, таким образом, что большая часть ОС может терпеть безразличное время виртуального диска без побочных эффектов?
Чтобы быть более точным, я хотел бы знать диск безразличное время, когда Windows NTFS, FreeBSD UFS/ZFS и Linux ext4 могут терпеть. Что включены параметры? (например, /sys/block/sda/device/timeout на Linux)
связанная информация:
Обновление: @the-wabbit ответил о Linux и Windows, я также хотел бы знать случай FreeBSD
Драйвер диска, как правило, ожидает превышения настраиваемого таймаута, прежде чем сообщить об ошибке в запрошенной операции.
Как Вы узнали, это /sys/block/ в Linux и по умолчанию 60 30 секунд. Windows хранит эту конфигурацию как глобальную настройку TimeoutValue (REG_DWORD) в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\ со значением по умолчанию 60 секунд.
Пока не будет сообщено об ошибке вверх по течению, вы не увидите никаких немедленных действий (например, ro-remount FS), даже после истечения таймаута вы, как правило, увидите больше действий по обработке ошибок (запись в журнал, сброс устройства и т.д.). ) до того, как ошибка будет передана обратно на верхний уровень.
Но имейте в виду, что будут и другие последствия, влияющие на общую доступность.
- приложения или системные службы могут реализовывать собственные таймауты и бросать исключения по истечении срока
- на серверах с высоким оборотом запросов, вы увидите заполнение очередей и исчерпание памяти, так как новые клиенты продолжают отправлять новые запросы, а старые запросы все еще ждут ответа от хранилища. Если у вас случайно окажется место для подкачки на неисправном устройстве, все запросы на входе/выходе из страницы будут останавливаться, фактически блокируя процессы, работающие на этих страницах памяти.
В общем, вы захотите, чтобы время обхода отказа было как можно меньше во время работы без преждевременных обходов отказа из-за случайных скачков нагрузки или сбоев в сети. Определение правильного значения для конкретного случая использования - это очень много пробной и ошибочной работы в течение длительного периода эксплуатации. Для серверных ВМ общего пользования я бы нацелился на что-то продолжительностью в 10 секунд, если это возможно и поддерживается вашей инфраструктурой
.Во FreeBSD имеется geom_mountver (https://www.freebsd.org/cgi/man.cgi?gmountver), который может быть использован для того, чтобы заставить ее выдержать любое время обхода отказа. Если вы используете ZFS, вам может понадобиться отключить таймер мертвеца; он будет паниковать, если ввод-вывод не завершится через 15 минут (IIRC).
.