Это правда, что можно смонтировать том GlusterFS на любой кирпич, и клиент FUSE автоматически обнаружит другие блоки и подключится к ним. Если первый кирпич выходит из строя, клиент переключится на один из других кирпичей. Итак, после начальной загрузки файловая система становится высокодоступной.
Однако, когда вы перезагружаете клиентский хост и кирпич, с которого вы установили его для начальной загрузки (например, в /etc/fstab) не работает, то клиент вообще не будет подключаться, пока вы вручную не укажете его на другой кирпич для его начальной загрузки.
Это может быть проблемой в сценарии, когда клиенты перезагружаются или добавляются, когда «основной» кирпич не работает. Например, в Amazon AWS предположим, что у вас есть два реплицируемых блока GlusterFS в разных зонах доступности. Когда зона доступности, в которой находится ваша «основная», выходит из строя или теряет связь, есть большая вероятность, что вы автоматически масштабируете дополнительные серверы в другой зоне доступности, чтобы справиться с возросшей там нагрузкой. Поскольку «первичный» недоступен, эти серверы не могут монтировать файловую систему, пока вы не настроите их для монтирования другого блока.
Как мне убедиться, что клиенты (новые или перезагружающиеся) будут пытаться подключиться к любому доступному кирпичу?
Мы используем Puppet для управления всеми узлами, включая содержимое /etc/fstab, и используют GlusterFS 3.9.
Если опция backupvolfile-server добавлена во время монтирования клиента fuse, когда первый сервер volfile выходит из строя, то сервер, указанный в опции backupvolfile-server, используется как сервер volfile для монтирования клиента.