Почему я не могу создать этот gluster объем?
Виртуализация не является необходимым компонентом для использования SAN, у Вас есть она наоборот. SAN является желательным (не требуемый) компонент для вытаскивания лучшего из основных развертываний виртуализации.
SAN полезен в виртуализации по крайней мере в двух областях:
Вам обычно нужно быстрое, большое дисковое хранилище для содержания изображений виртуального диска. SAN является распространенным способом достигнуть обеих из тех вещей.
Одна часть больших установок виртуализации, таких как VMware ESX и HyperV является способностью "переместить" виртуальные машины от одного хоста до другого, и как часть планирования мощностей и улучшить доступность в случае отказа оборудования на хосте. Чтобы сделать это, Вам нужна совместно используемая память, и сделать это правильно Вам нужна совместно использованная надежная система хранения.
И для тех случаев, SAN не является единственным способом сделать вещи, и это даже не мог бы быть самый дешевый способ сделать вещи, но он действительно решает проблему и обычно решает их очень хорошо.
На моей LAN у нас есть и VMware виртуальные хосты и непосредственно серверы прикрепленного файла, использующие SAN. Мы используем любую комбинацию, которую мы чувствуем, будет эффективным для каждой конкретной проблемы, которую мы решаем.
Я видел непонятное сообщение об ошибке о неподключенном сокете с одноранговым узлом 127.0.0.1.
[2013-08-16 00: 36: 56.765755] Вт [socket.c: 1494: __ socket_proto_state_machine] 0-socket.management: чтение из сокета не удалось. Ошибка (конечная точка транспорта не connected), peer (127.0.0.1:1022)
Оказывается, проблема у меня была из-за NAT. Я пытался создать серверы Gluster, которые находились за устройством NAT и использовали общедоступный IP-адрес для разрешения имен. Это просто не будет работать должным образом на локальной машине.
На каждом узле у меня было что-то вроде следующего.
Файл hosts, содержащий
192.168.0.11 gluster1
192.168.0.12 gluster2
192.168.0.13 gluster3
192.168.0.14 gluster4
Исправление заключалось в том, чтобы сначала удалить доверенные узлы
sudo gluster peer detach gluster2
sudo gluster peer detach gluster3
sudo gluster peer detach gluster4
Затем измените файл hosts на каждой машине на
# Gluster1
127.0.0.1 gluster1
192.168.0.12 gluster2
192.168.0.13 gluster3
192.168.0.14 gluster4
# Gluster2
192.168.0.11 gluster1
127.0.0.1 gluster2
192.168.0.13 gluster3
192.168.0.14 gluster4
и т. Д.
Затем выполните одноранговое зондирование и, наконец, создайте том, который затем был успешным.
Я сомневаюсь, что использование IP-адресов (общедоступных) сработает в этом случае . Это должно работать, если вы используете частные адреса за NAT. В моем случае каждый сервер находился за NAT в облаке AWS.
Попробуйте явно определить количество реплик как четыре узла, используя следующий формат: -
gluster volume create NEW-VOLNAME [stripe COUNT] [replica COUNT] [transport <tcp | rdma>] NEW-BRICK ...
Я предполагаю, что это чистая реплика без полосы?
попробуйте это из 192.168.0.11: -
сначала отсоедините все:
sudo gluster peer detach 192.168.0.12
sudo gluster peer detach 192.168.0.13
sudo gluster peer detach 192.168.0.14
затем повторно добавьте в этом формате
gluster volume create gv0 replica 4 transport tcp 192.168.0.11:/export/brick1 192.168.0.12:/export/brick1 192.168.0.13:/export/brick1 192.168.0.14:/export/brick1
Примечание Я явно определил этот набор реплик из четырех узлов. также я явно определил транспорт через tcp .
если вы хотите разделить два устройства в наборе реплик, вы должны использовать что-то вроде этого: -
gluster volume create gv0 stripe 2 replica 2 transport tcp 192.168.0.11:/export/brick1 192.168.0.12:/export/brick1 192.168.0.13:/export/brick1 192.168.0.14:/export/brick1
Продолжайте, я недавно обнаружил gluster и я влюблен в эту идеологию распределенных файловых систем ... настоящее произведение искусства.
Я использую gluster для обеспечения HA-избыточности виртуальных хранилищ данных KVM. магия