Предложение по созданию тома GlusterFS

Предложение по созданию тома GlusterFS

Мне нужно развернуть несколько кластеров Openshift от 3 до 10 узлов. Для 3 узлов я создаю тома как реплицированные.

Но для 4 и выше не выглядит красиво создавать реплицированный том, поэтому каждый узел имеет диск на 300 ГБ, и реплицировать его на 10 узлов не оптимально. Я ищу формулу для использования типа

For 4 nodes create volume as disperse:2:1
For 5 nodes create volume as disperse:?:?
For 6 nodes create volume as disperse:?:?
For 7 nodes create volume as disperse:?:?
For 8 nodes create volume as disperse:?:?
For 9 nodes create volume as disperse:?:?
For 10 nodes create volume as disperse:?:?

Среда: Я буду использовать эти тома для MYSQL 5.7.28, и каждый сервер будет иметь диск объемом 300 ГБ. Из 300 ГБ я создам том размером 250 ГБ для MYSQL.

OpenShift 3.11 version

# gluster --version
glusterfs 6.1

PS: у меня нет опыта хранения данных, так что извините, если я упускаю какие-то очевидные моменты. Я пытался искать в Google, но не смог извлечь необходимую информацию.

решение1

Планируете ли вы использовать все узлы как узлы хранения или только подмножество узлов как узлы хранения? Исходя из вашего вопроса, MySQL использует 250GiB, каким другим приложениям нужно хранилище?

Копировать том: Эффективное доступное пространство для хранения будет

volume_size = sum of storage available from three nodes / 3

В вашем случае размер тома составит 300 ГиБ с использованием трех узлов хранения.

Распределение объема: эффективное доступное пространство для хранения будет

volume_size = storage in single node * (number of bricks - redundancy count)

В вашем случае размер тома будет 300 * (3-1) = 600GiB. Более подробная информация доступна здесьhttps://docs.gluster.org/en/v3/Administrator%20Guide/Setting%20Up%20Volumes/#creating-dispersed-volumes Disperse Volumes хороши для архивных целей, поскольку они могут экономить место по сравнению с Replica volumes. Но они могут быть медленными по сравнению с Replica из-за вычислений, используемых при каждом IO.

Кадалу(https://kadalu.io) проект предоставляет другой подход к предоставлению томов в Kubernetes. Он создает один том Gluster из хранилища и предоставляет подтома из этого тома при запросе PV (в вашем случае хранилище для Mysql).

В настоящее время Kadalu поддерживает тома Replica 1 и Replica 3. Replica 1 полезна, когда устройство хранения запрашивается у других поставщиков хранилищ, например, AWS/Azure. Replica 3 обеспечивает высокую доступность хранилища для приложений, даже если один из трех узлов выходит из строя. Недавняя запись в блоге (https://kadalu.io/blog/kadalu-kubernetes-storage) объясняет несколько конфигураций, доступных в Kadalu, и их использование с существующим хранилищем.

Kadalu использует GlusterFS и изначально интегрирован с Kubernetes, без использования демона управления Gluster - glusterd.

Обновлять: Добавлены расчеты для рассеиваемого объема

number of disperse bricks = data bricks + redundancy count

Если доступны 3 устройства хранения данных,

2 data bricks + 1 redundancy bricks

В случае 6 устройств хранения данных,

4 data bricks + 2 redundancy bricks

Если количество блоков избыточности увеличивается, то полезный размер Volume будет уменьшаться. Volume будет доступен приложениям, даже если количество блоков, эквивалентных блокам избыточности, уменьшится. Например, в 4+2конфигурации Volume будет доступен, даже если 2 блока из 6 выйдут из строя.

Связанный контент