Здесь мы сталкиваемся с проблемой, когда общий том кластера, подключенный к нашему кластеру Hyper-V 2012 R2, отключается или выходит из строя при малейшем прерывании соединения iSCSI SAN, которое он использует. Это, конечно, проблема, поскольку это приводит к сбою или отключению всех виртуальных машин.
Прерывания в подключении iSCSI SAN происходят, когда основной узел SAN переключается на свою реплику. До того, как вторичный сработает, остается около 10-15 секунд простоя. Мы используем решение на основе FreeBSD + ZFS в сочетании с HAST + CARP для обеспечения хранилища высокой доступности.
Отработка отказа работает, когда некластеризованный iSCSI LUN монтируется на стороне Windows, например, обычное соединение с инициатором. Ввод / вывод просто приостанавливается, пока соединение не будет восстановлено. Я ожидал того же поведения с CSV, но, увы, он кажется очень требовательным к тайм-аутам ввода-вывода.
Есть ли способ увеличить время ожидания CSV или, возможно, какое-то другое решение этой проблемы?
видели, как это происходит со многими людьми.
в большинстве случаев проблема заключается в следующем:
трафик резервного копирования не полностью изолирован от трафика управления кластером. Так как Ethernet - это ужасно, увеличение количества конфликтов пакетов резко снижает полосу пропускания и время приема-передачи тактового сигнала. а потом бум! CSV не работает
Другой распространенной проблемой является слишком низкая общая скорость Ethernet по сравнению с общей нагрузкой. когда начинается резервное копирование, вы получаете огромный всплеск трафика по разным причинам.
насколько мне известно, нет способа продлить тайм-аут. CSV очень требователен к таймауту сердцебиения. Столкнувшись с этой проблемой на нескольких сайтах, мы установили ограничение скорости ввода-вывода в BackupChain, чтобы снизить риск возникновения этой проблемы. Однако реальное решение состоит в том, чтобы в первую очередь избежать этих разрывов соединения, из того, что я видел до сих пор ...