Gpfs что это такое
Перейти к содержимому

Gpfs что это такое

  • автор:

Российский системный интегратор
Серверы и сетевое оборудование
Суперкомпьютеры и HPC-кластеры
Импортозамещение в сфере ИТ

Несмотря на сложившуюся ситуацию, мы заботимся о наших клиентах и осуществляем обслуживание заявок и контрактов. Звоните и пишите нам, мы на связи!

Сервер хранения данных Lenovo General Parallel File System (GPFS) – идеальное решение для СХД большой емкости и высокой производительности

Импортозамещение систем хранения данных! Акция! При покупке любой российской СХД Аэродиск — серверный шкаф в подарок. Количество ограничено!

Спецпредложения

side

Сервер хранения данных Lenovo General Parallel File System (GPFS) – это многолетний опыт передовых разработчиков ИТ-оборудования, который воплощен в высокотехнологичном комплексе для поддержки современных ЦОД. Новое оборудование позволит поддерживать облачные и высокопроизводительные вычисления HPC, работать с инструментами аналитики и развертывать многофункциональные системы инженерных расчетов.

Цена: 0 руб.* (по запросу)
Вы можете заказать это оборудование в лизинг Подробнее
Описание Характеристики

Описание Lenovo General Parallel File System (GPFS)

Сервер хранения данных Lenovo General Parallel File System (GPFS) относится к высокопроизводительным системам, созданным для работы с мощными системами хранения данных, которые используются для кластеров Intelligent Cluster. Новая интегрированная система поддерживает модульный подход формирования масштабируемых хранилищ. Это позволит легко адаптировать оборудование к тому, чтобы решать разноплановые задачи, к которым относятся следующие:

  • поддержка средств бизнес аналитики;
  • работа с ресурсоемкими системами дистанционного образования;
  • поддержка ресурсоемких инженерных расчетов;
  • использование в процессе научных исследований.

Новые возможности

Lenovo General Parallel File System (GPFS) отличаются от аналогичного оборудования следующими нюансами:

  • упрощенная интегрированная система хранения информации;
  • поддержка файловой системы General Parallel File System;
  • использование модельного подхода к масштабированию;
  • использование RAID-массивов на базе GPFS;
  • высокая скорость работы и уникальный уровень безопасности обрабатываемых данных;
  • оптимальное соотношение цены и качества.

Эффективность и практичность

Серверы хранения данных Lenovo General Parallel File System воплотили в своей конфигурации мощность и функциональность лучших серверных систем System x, многогранность современного специализированного программного обеспечения и модульный подход к масштабированию рабочего потенциала. Используя серверные системы хранения данных GPFS, компании могут начинать с небольших сетей, впоследствии расширяя их емкость и потенциал посредством добавления нужного количества модулей GSS. Благодаря этому можно достичь высоких показателей производительности с оптимальным распределением своих финансовых средств.

Технические характеристики сервера хранения данных Lenovo General Parallel File System (GPFS)

  • Model 21s: 1
  • Model 22s: 2
  • Model 24: 4
  • Model 26: 6
  • Model 21s: 1.2TB
  • Model 22s: 1.2TB
  • Model 24: 3, 4, 6TB
  • Model 26: 3, 4, 6TB
  • Model 21s: 24
  • Model 22s: 48
  • Model 24: 232
  • Model 26: 348

General Parallel File System

General Parallel File System (GPFS, Общая параллельная файловая система) — высокопроизводительная кластерная файловая система, разработанная IBM. GPFS отличается от других кластерных файловых систем возможностью одновременного высокоскоростного доступа к файлам для приложений, выполняющихся на нескольких узлах кластера под управлением операционных систем AIX 5L, Linux или гетерогенного кластера из узлов на AIX, Linux и Windows. Помимо возможностей хранения данных, GPFS предоставляет инструменты для управления и администрирования GPFS-кластера и позволяет осуществлять совместный доступ к файловым системам с удалённых GPFS-кластеров.

GPFS предоставляет высокопроизводительный доступ к данным как для одного узла, так и для множества. Самая большая существующая на данный момент конфигурация состоит из 2000 узлов. [источник не указан 869 дней] GPFS доступна для AIX с 1998 года, на Linux с 2001 года и на Windows с 2009 года.

История

GPFS изначально разрабатывалась как Tiger Shark file system в 1993 году в исследовательском центре IBM Almaden Research Center. Первый коммерческий релиз GPFS состоялся в 1998 году.

GPFS изначально проектировалась для поддержки мультимедиа-приложений, требовательных к полосе пропускания. Такой дизайн хорошо подходит для научных вычислений. Сегодня GPFS используется на многих суперкомпьютерах из списка 500 самых мощных. С самого начала GPFS была успешно использована для множества коммерческих приложений.

Ссылки

  • Официальная страница (англ.)
  • GPFS на SourceForge

Установка большого Linux-кластера: Часть 4. Установка узлов и настройка GPFS-кластера

Пасека Старчевских

Это четвертая и последняя статья серии, посвященной установке и настройке большого Linux-кластера. Целью данной серии является объединение в одном месте последней информации из разнообразных общедоступных источников о создании работающего Linux-кластера из множества отдельных частей аппаратного и программного обеспечения. В этих статьях не описываются основы проектирования нового большого Linux-кластера, а лишь предоставляются ссылки на соответствующие справочные материалы и Redbooks™ по общей архитектуре.

Данная серия статей предназначена для использования системными разработчиками и системными инженерами при планировании и внедрении Linux-кластера при помощи интегрированной среды IBM eServer Cluster 1350 (ссылки на дополнительную информацию по данной среде приведены в разделе «Ресурсы»). Некоторые статьи могут быть полезны администраторам как в качестве учебных материалов, так и при использовании в процессе эксплуатации кластера. Каждая часть данной серии статей ссылается на один и тот же пример установки.

В первой части данной серии приведены подробные инструкции по установке аппаратного обеспечения кластера. Во второй части рассматриваются следующие после конфигурирования оборудования действия: установка программного обеспечения при помощи программы управления системами IBM Cluster Systems Management (CSM) и установка узлов.

Третья часть и эта статья описывают систему хранения данных кластера, включая установку и настройку аппаратного обеспечения системы хранения данных, а также настройку файловой системы IBM с совместным доступом General Parallel File System (GPFS). В третьей части рассмотрена архитектура системы хранения данных, подготовка аппаратного обеспечения и подробная информация по установке Storage Area Network. В данной, четвертой и последней, части серии подробно рассматриваются специфические вопросы CSM, относящиеся к системе хранения данных нашего примера кластера, в частности, установка узлов для системы хранения данных и настройка GPFS-кластера.

В данном разделе детализируются специфические вопросы управления сервером кластера (cluster server management — CSM), связанные с системой хранения данных примера кластера. К ним относятся установка GPFS-кода на каждом узле и настройка адаптеров Qlogic для узлов системы хранения. Обращаем внимание на то, что эта настройка не обязательно должна выполняться с использованием CSM; ее можно сделать и вручную. В примере данной статьи используется CSM для практически полной автоматизации установки нового сервера, в том числе и сервера хранения данных.

Перед прочтением данного раздела полезно повторить материал раздела «Общая архитектура кластера» из первой статьи данной серии. Также полезно просмотреть раздел по архитектуре системы хранения данных в третьей статье. Понимание архитектуры обеспечит необходимый контекст для наилучшего использования приведенной ниже информации.

Установка в нужном порядке является обязательным условием для устранения проблемы переполнения ROM, описанной позже, поскольку используемые в данной конфигурации системы xSeries™ 346 не имеют карт RAID 7K. Выполните следующие действия в указанном порядке:


    Выполните команду csmsetupks -vxn на управляющем сервере.

GPFS требует, чтобы все узлы в GPFS-кластере были способны обращаться друг к другу, используя root ID без предоставления пароля. GPFS использует этот межузловой доступ, чтобы разрешить любому узлу в GPFS-кластере выполнять соответствующую команду на других узлах. В приведенном в этой статье примере для предоставления доступа используется ssh (secure shell), однако можно использовать также rsh (remote shell). Для этого создайте ключ, относящийся ко всему кластеру, и соответствующие конфигурационные файлы, которые распределите при помощи CSM, выполнив следующие действия:


    Создайте два новых каталога в /cfmroot/root/.ssh и /cfmroot/etc/ssh .

ssh-keygen -b 1024 -t rsa -f /cfmroot/etc/ssh/ssh_host_rsa_key -N "" -C "RSA_Key"
ssh-keygen -b 1024 -t dsa -f /cfmroot/etc/ssh/ssh_host_dsa_key -N "" -C "DSA_Key"
cat /root/.ssh/id_rsa.pub > /cfmroot/root/.ssh/authorized_keys2 cat /root/.ssh/id_dsa.pub >> /cfmroot/root/.ssh/authorized_keys2 cat /cfmroot/etc/ssh/ssh_host_rsa_key.pub >> /cfmroot/root/.ssh/authorized_keys2 cat /cfmroot/etc/ssh/ssh_host_dsa_key.pub >> /cfmroot/root/.ssh/authorized_keys2
stopcondresp NodeFullInstallComplete SetupSSHAndRunCFM startcondresp NodeFullInstallComplete RunCFMToNode perl -pe 's!(.*update_known_hosts.*)!#$1!' -i /opt/csm/csmbin/RunCFMToNode
#!/bin/bash RSA_PUB=$(cat "/cfmroot/etc/ssh/ssh_host_rsa_key.pub") DSA_PUB=$(cat "/cfmroot/etc/ssh/ssh_host_dsa_key.pub") for node in $(lsnodes); do ip=$(grep $node /etc/hosts | head -n 1 | awk '') short=$(grep $node /etc/hosts | head -n 1 | awk '') echo $ip,$node,$short $RSA_PUB echo $ip,$node,$short $DSA_PUB done

Файловые системы (список • сравнение)
Дисковые

Этот пример сценария работает для одиночного интерфейса. Вы можете просто изменить его, чтобы разрешить беспарольный доступ для нескольких интерфейсов. Обсуждение формата файла known_hosts выходит за рамки данной статьи, но полезно использовать разделенные запятыми имена хостов в отдельных строках.

cd /cfmroot/root/.ssh ln -s ../../etc/ssh/ssh_host_dsa_key id_dsa ln -s ../../etc/ssh/ssh_host_dsa_key.pub id_dsa.pub ln -s ../../etc/ssh/ssh_host_rsa_key id_rsa ln -s ../../etc/ssh/ssh_host_rsa_key.pub id_rsa.pub

Для данного примера определяются две главных CSM-группы, использующиеся во время настройки GPFS, как показано ниже.


    StorageNodes , включающая только те узлы, которые подключаются напрямую к SAN, например, nodegrp -w «Hostname like ‘stor%'» StorageNodes .

Эти группы используются во время установки, чтобы гарантировать получение серверами, выполняющими роли узлов системы хранения данных, специфичных бинарных и конфигурационных файлов, которые детально рассмотрены ниже. Обратите внимание на то, что в данном разделе не описывается подробно процедура установки, выполняемая CMS. Инструкции по этой процедуре приведены в первой и второй статьях данной серии.

Обобщенно процесс установки проходит следующие этапы:

  1. PXE-загрузка/DHCP с сервера установки.
  2. Установка NFS с сервера установки.
  3. Сценарии, выполняющиеся до перезагрузки (pre-reboot).
  4. Перезагрузка.
  5. Сценарии, выполняющиеся после перезагрузки (post-reboot).
  6. Передача CFM-файла.
  7. Послеустановочная настройка CSM.

Изменения конфигурации в данной статье происходят на этапах pre-reboot и передачи CFM-файла.

GPFS требует наличия на каждом члене кластера базового набора установленных RPM-файлов GPFS. В примере использовалась GPFS версии 2.3.0-3. Установка этих RPM представляет собой процесс из двух этапов: установка базовой версии 2.3.0-1 и последующее обновление до 2.3.0-3. Для данной установки использовались следующие RPM-файлы:

  • gpfs.base
  • gpfs.docs
  • gpfs.gpl
  • gpfs.msg.en_US

Примечание: Поскольку пример использует GPFS Version 2.3, установка Reliable Scalable Cluster Technology (RSCT) и создание домена одноранговой сети (peer) не требуется. Версии GPFS до Version 2.3 требовали выполнения этих действий вручную.

CSM может установить RPM-файлы GPFS различными способами. В данной статье рекомендуется устанавливать RPM на этапе установки базовой операционной системы. CSM предоставляет структуру каталогов установки и обновления, содержащую настроенные RPM-файлы, однако это может работать не очень хорошо в случае первоначальной установки RPM, за которой выполняется обновление этих же RPM, что нужно для GPFS 2.3.0-3.

Одним из альтернативных методов является написание сценариев для CSM (выполняющихся до перезагрузки и после установки), чтобы установить необходимые RPM-файлы. В данном случае скопируйте все RPM-файлы GPFS, включая RPM-файлы обновления, в каталог /csminstall/Linux управляющего сервера. CSM обычно резервирует каталог для данных сценариев /csminstall/csm/scripts/data , который будет монтироваться к узлу во время установки, делая необходимые RPM-файлы доступными через NFS.

Напишите сценарий /csminstall/csm/scripts/installprereboot/install-gpfs.sh для установки GPFS. Вот пример такого сценария:

#! /bin/bash # Устанавливает набор файлов GPFS и обновляет до последних версий # Переменная среды CSMMOUNTPOINT устанавливается CSM DATA_DIR=$CSMMOUNTPOINT/csm/scripts/data cd $DATA_DIR rpm -ivh gpfs.*2.3.0-1*.rpm rpm -Uvh gpfs.*2.3.0-3*.rpm echo 'export PATH=$PATH:/usr/lpp/mmfs/bin' > /etc/profile.d/gpfs.sh

После установки GPFS на сервере хранения данных вы, возможно, также захотите автоматически установить программу FAStT MSJ, что можно сделать в невидимом (не интерактивном) режиме. MSJ используется для настройки адаптеров Qlogic, системы восстановления после сбоев и нескольких каналов передачи, что подробно описывается в разделе по настройке HBA. Установка не основывается на RPM-файлах, поэтому нелегко интегрировать ее в CSM по умолчанию. Для выполнения установки вы можете добавить сценарий в конец установки GPFS для проверки того, является ли узел сервером хранения данных, а также для установки MSJ. Для установки в невидимом режиме используйте команду FAStTMSJ*_install.bin -i silent

Пример кластера использует драйвер Qlogic qla2300 версии 7.01.01 для адаптеров Qlogic QLA 2342. Каждый из узлов в группе узлов системы хранения данных имеет два таких PCI-адаптера. Драйвер qla2300 поставляется стандартно с дистрибутивом Red Hat Enterprise Linux 3 update 4. Однако вы должны выполнить следующие изменения для примера кластера:


    Измените драйвер qla2300 на выполнение восстановления после сбоев. Это позволит вам воспользоваться другим путем к диску и восстановить работоспособность после возникновения сбоя в предпочтительном пути. По умолчанию эта функция отключена. Первое изменение выполните с использованием сценария, выполняющегося CSM перед перезагрузкой во время установки. Выполняющий это действие сценарий находится в каталоге /csminstall/csm/scripts/installprereboot/ . Этот сценарий содержит следующие команды:

#! /bin/bash # Добавляет строки в /etc/modules.conf для разрешения системы # восстановления после сбоев для драйверов qla2300 echo "options qla2300 ql2xfailover=1 ql2xmaxsectors=512 ql2xmaxsgs=128" >> /etc/modules.conf echo "Updating initrd with new modules.conf set up" mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`

Пример предлагает добавить несколько строк в файл /etc/sysctl.conf на каждом узле для тонкой настройки GPFS-сети. Это выполняется с использованием установочного сценария CSM, выполняющегося после перезагрузки. Сценарий расположен в каталоге /csminstall/csm/scripts/installpostreboot и содержит следующие строки:

FILE=/etc/sysctl.conf # Добавляет строки в /etc/sysctl.conf для тонкой настройки GPFS-сети echo "# CSM added the next 8 lines to the post installation script for GPFS network tuning" >> $FILE echo "# increase Linux TCP buffer limits" >> $FILE echo "net.core.rmem_max = 8388608" >> $FILE echo "net.core.wmem_max = 8388608" >> $FILE echo "# increase default and maximum Linux TCP buffer sizes" >> $FILE echo "net.ipv4.tcp_rmem = 4096 262144 8388608" >> $FILE echo "net.ipv4.tcp_wmem = 4096 262144 8388608" >> $FILE echo "# increase max backlog to avoid dropped packets" >> $FILE echo "net.core.netdev_max_backlog=2500" >> $FILE # Следующие строки не относятся к настройке GPFS echo "# Allow Alt-SysRq" >> $FILE echo "kernel.sysrq = 1" >> $FILE echo "# Increase ARP cache size" >> $FILE echo "net.ipv4.neigh.default.gc_thresh1 = 512" >> $FILE echo "net.ipv4.neigh.default.gc_thresh2 = 2048" >> $FILE echo "net.ipv4.neigh.default.gc_thresh3 = 4096" >> $FILE echo "net.ipv4.neigh.default.gc_stale_time = 240" >> $FILE # Сброс текущих параметров ядра sysctl -p /etc/sysctl.conf

Уровень переносимости (portability layer — PL) GPFS является зависимым от ядра и должен быть создан отдельно для каждой версии операционной системы вашего кластера. Назначение PL и подробная информация по созданию для примера кластера описаны в разделе «Создание и установка уровня переносимости». Скопируйте бинарные файлы PL в каталог /cfmroot/usr/lpp/mmfs/bin управляющих серверов и назовите их так, чтобы они распределялись только на узлы с определенными версиями ядра в соответствующих группах. Например:

/cfmroot/usr/lpp/mmfs/bin/dumpconv._ /cfmroot/usr/lpp/mmfs/bin/lxtrace._ /cfmroot/usr/lpp/mmfs/bin/mmfslinux._ /cfmroot/usr/lpp/mmfs/bin/tracedev._

Обратите внимание на то, что в большом кластере для уменьшения нагрузки на CFM можно добавить эти четыре файла в специализированный RPM и установить вместе с GPFS, используя метод, приведенный выше для установки RPM-файлов GPFS.

Простой установки GPFS RPMS и уровня переносимости недостаточно для монтирования и настройки файловых систем в GPFS-кластере на новых установленных узлах. Однако масштабирование кластера до больших размеров оправдывает автоматизацию данного шага. Это можно сделать с использованием мониторинговых возможностей CSM для отслеживая завершения установки нового узла и запуска сценария для настройки и монтирования GPFS на новом узле в кластере.

В листинге 1 показан пример сценария, который может быть использован для настройки GPFS. Вам, возможно, понадобится несколько изменить его для вашей конфигурации. В листинге предоставлена основа. Сценарий принимает имя узла (переданное CSM-мониторами), добавляет его в GPFS-кластер и пытается запустить GPFS на этом узле с некоторой тривиальной обработкой ошибок.

#!/bin/bash # Сценарий CSM условие/ответ, используемый в качестве ответа на условие # InstallComplete. Он будет пытаться добавить узел в GPFS-кластер, обрабатывая # попутно некоторые обычные ошибочные ситуации. # Выполняются только тривиальные действия; более сложные проблемы должны # решаться вручную. # Примечание: требуется файл GPFS gpfs-nodes.list. Этот файл должен содержать список # всех узлов в GPFS-кластере с подробной информацией клиент/менеджер и # кворум/отсутствие кворума, подходящей для передачи в команду mmcrcluster. # Выводимая информация направляется в /var/log/csm/ # Возвращаемые коды ошибок: # 1 - GPFS уже активен # 2 - нельзя прочитать файл gpfs-nodes.list # 3 - отсутствует имя узла в файле gpfs-nodes.list # 4 - узел является узлом кворума # 5 - нельзя добавить узел в кластер (mmaddnode выполнилась неудачно) # 6 - нельзя запустить GPFS на узле (mmstartup выполнилась неудачно) # укажите месторасположение вашего файла со списком узлов gpfs_node_list=/etc/gpfs-nodes.list # укажите интерфейс GPFS, используемый для взаимодействия gpfs_interface=eth1 PATH=$PATH:/usr/lpp/mmfs/bin # ensure GPFS binaries are in the PATH log_file=/var/log/csm/`basename $0`.log # log to /var/log/csm/ touch $log_file # Получить краткое имя узла, установленное RSCT-условием ENV var ERRM_RSRC_NAME node=`echo $ERRM_RSRC_NAME | cut -d. -f1` ( [ ! -r "$gpfs_node_list" ] && echo " ** error: cannot read GPFS node list $gpfs_node_list" && exit 2 echo echo "--- Starting run of `basename $0` for $node at `date`" # Является ли узел узлом кворума? Если да, выйти. quorum_status=`grep $node $gpfs_node_list | cut -d: -f2 | cut -d- -f2` if [ -n "$quorum_status" ]; then if [ "$quorum_status" = "quorum" ]; then echo "** error: this is a quorum node, stopping. " exit 4 else node_s=`grep $node $gpfs_node_list | cut -d: -f1` fi else echo "** error: could not find node $node in GPFS node list $gpfs_node_list" exit 3 fi # Определить, является ли уже узел частью кластера if mmlscluster | grep $node >/dev/null; then # проверить состояние узла status=`mmgetstate -w $node | grep $node | awk ''` if [ "$status" = "active" ]; then echo "** error: this node already appears to have GPFS active!" exit 1 fi # попытаться удалить узел из кластера echo "Node $node is already defined to cluster, removing it" # попытаться запретить интерфейс системы хранения данных на узле if ssh $node $ifdown $gpfs_interface; then mmdelnode $node ssh $node ifup $gpfs_interface else echo "** error: could not ssh to $node, or ifdown $gpfs_interface failed" fi fi # попытаться добавить узел в GPFS-кластер if mmaddnode $node; then echo "Successfully added $node to GPFS cluster, starting GPFS on $node" if mmstartup -w $node; then echo "mmstartup -w $node succeeded" else echo "** error: cannot start GPFS on $node, please investigate" exit 6 fi else echo "** error: could not add $node to GPFS cluster" exit 5 fi ) >>$log_file 2>&1

Можно использовать CSM для автоматического запуска сценария, приведенного в листинге 1, после завершения базовой установки операционной системы на узле, так чтобы при ее загрузке автоматически монтировалась файловая система GPFS. Прежде всего, вы должны определить сценарий как механизм ответа в CSM-мониторе. Например: mkresponse -n SetupGPFS -s /path/to/script/SetupGPFS.sh SetupGPFS .

Теперь у вас имеется ответ под названием SetupGPFS, который будет запускать ваш сценарий. Затем вы должны назначить этот ответ CSM-условию по умолчанию NodeFullInstallComplete следующим образом: startcondresp NodeFullInstallComplete SetupGPFS .

Теперь CSM всегда будет автоматически запускать сценарий с управляющего сервера при установке нового узла. На управляющем сервере CSM вы можете увидеть условие NodeFullInstallComplete , связанное с ответом SetupGPFS , при запуске команды lscondresp . Условие или ответ должны быть указаны как Active .

Существует известная проблема с объемом ROM-памяти, доступной на xSeries 346, — ошибки распределения PCI во время загрузки. Сообщения указывают, что системная ROM-память заполнена, и больше нет места для дополнительных адаптеров, использующих память ROM (более подробно в разделе «Ресурсы»).

Эта проблема влияет на узлы системы хранения данных, поскольку, если разрешена PXE-загрузка, нет достаточного объема памяти для корректной инициализации PCI-адаптеров Qlogic. Вот один из способов решения данной проблемы:


    Запретите PXE-загрузку на PCI-карте Broadcom, используемой для GPFS-сети. Используя доступную для загрузки возможность diag b57udiag -cmd, выберите устройство, а затем запретите PXE-загрузку.

Другое решение проблемы — использование карты RAID 7K в каждой xSeries 346. Она уменьшит объем ROM, используемый SCSI BIOS, и позволит успешно загрузиться Qlogic BIOS даже с разрешенной PXE-загрузкой.

На серверах хранения данных xSeries 346 примера кластера в качестве HBA используются адаптеры модели IBM DS4000 FC2-133 Host Bus Adapter (HBA). Они известны также под названием Qlogic 2342. В примере используется версия встроенной микропрограммы 1.43 и, как упоминалось в предыдущем разделе, драйвер v7.01.01-fo qla2300. Суффикс -fo драйвера обозначает функциональность восстановления после сбоев, которая не является параметром по умолчанию для этого драйвера. Данная функциональность разрешается путем изменения настроек в /etc/modules.conf на каждом узле системы хранения данных. Это действие выполняется при помощи CSM во время установки и описано в разделе «Настройка системы восстановления после сбоев Qlogic».

В следующем разделе описываются действия, необходимые для обновления встроенной микропрограммы и настроек в HBA-адаптерах на каждом сервере хранения данных, а также ручная процедура разрешения функциональности распределения нагрузки между двумя HBA-адаптерами, которую нужно выполнять при каждой повторной установки.

Микропрограмму для HBA-адаптеров FC2-133 можно выполнить с Web-сайта поддержки IBM System x (см. раздел «Ресурсы»). Обновить микропрограмму можно при помощи IBM Management Suite Java, или используя загрузочную дискету и программу flasutil.

Для данного примера кластера были изменены (со значений по умолчанию) приведенные ниже настройки HBA-адаптеров. Значения можно найти в файле README, поставляемом вместе с драйвером. Изменения можно сделать в Qlogic BIOS, который вызывается во время загрузки путем нажатия комбинации клавиш -q при запросе либо при помощи служебной программы MSJ. Вот эти настройки:

  • Настройки адаптера хоста
    • Loop reset delay: 8

    • LUNs per target: 0
    • Enable target reset : Yes
    • Port down retry count: 12

    IBM FAStT Management Suite Java (MSJ) — это Java-приложение с графическим интерфейсом пользователя (GUI), управляющее HBA-адаптерами в управляющих серверах. Его можно использовать для настройки и диагностики. Ссылки на источники для загрузки этой программы приведены в разделе «Ресурсы».

    В нашем примере используется CSM для установки MSJ на каждом узле системы хранения данных как части общей установки GPFS. Бинарный файл является частью tar-файла, содержащего RPM-файлы GPFS, который CFS распространяет во время установки CSM-узла. Сценарий, выполняющийся после установки, разархивирует этот tar-файл, который, в свою очередь, запускает сценарий установки, содержащийся внутри tar-файла. В примере используется 32-разрядная версия FAStT MSJ, чтобы обойти потенциальные проблемы, возможные при установке 64-разрядной версии. Пример сценария использует следующую команду для установки MSJ: FAStTMSJ*_install.bin -i silent .

    Устанавливается приложение и агент. Обратите внимание на то, что поскольку это 32-разрядная версия MSJ, даже при том, что пример использует не интерактивную установку, код ищет и загружает 32-разрядные версии некоторых библиотек. Следовательно, используйте установленную 32-разрядную версию XFree86-libs, также как 64-разрядную версию, включаемую при базовой 64-разрядной установке. 32-разрядные библиотеки содержатся в файле XFree86-libs-4.3.0-78.EL.i386.rpm, включенном в tar-файл. Установкой этого rpm-файла занимается сценарий install.sh, который затем устанавливает MSJ.

    Наличие MSJ требуется на каждом узле системы хранения данных для ручной настройки путей к массивам на DS4500 и распределения нагрузки между двумя HBA-адаптерами на каждом компьютере. Если эту настройку не выполнить, по умолчанию все массивы будут доступны через первый адаптер на каждом компьютере (HBA0) и, соответственно, через контроллер A на каждой системе DS4500. Распределяя диски между HBA-адаптерами и, следовательно, между двумя контроллерами на DS4500, вы распределяете нагрузку и улучшаете производительность сервера.

    Обратите внимание на то, что настройка распределения нагрузки является ручным процессом и должна выполняться на каждом узле системы хранения данных при каждой его переустановке. Для нашего примера кластера нужно выполнить следующие действия по настройке распределения нагрузки:


      Откройте новое окно на локальном компьютере из вновь установленного сервера с установкой xforwarding ( ssh -X ).

    Одним из наиболее эффективных способов использования MSJ при установке (когда нужно выполнить настройку распределения нагрузки на более чем одном узле системы хранения данных) является сохранение MSJ в открытом состоянии на одном узле, запуск qlremote на каждом из остальных узлов и использование одной MSJ-сессии для подключения к ним.

    В данном разделе подробно описаны действия по созданию GPFS-кластера. Здесь предполагается, что все узлы были установлены и настроены так, как рассматривалось ранее в данной статье, либо что была выполнена вручную следующая настройка:


      RPM-файлы GPFS установлены на каждом компьютере.

    Подробное описание архитектуры GPFS для примера кластера приведено в разделе «Архитектура системы хранения» в третьей статье данной серии.

    Прочтите данный раздел статьи параллельно с документацией по GPFS (см. раздел «Ресурсы»), в частности, следующие материалы:


      Справочник по администрированию и программированию GPFS V2.3 , содержащий подробную информацию о многих административных задачах и GPFS-командах.

    Уровень переносимости (portability layer — PL) GPFS представляет собой набор бинарных файлов, которые должны быть скомпонованы локально из исходных кодов для соответствия ядру Linux и конфигурации компьютера, являющегося частью GPFS-кластера. Для нашего примера кластера это было сделано на одном из узлов системы хранения данных. Полученные в результате файлы были скопированы на каждый узел при помощи CSM и CFM (более подробная информация приведена в разделе «Распределение уровня переносимости GPFS»). Это корректный метод, поскольку все компьютеры имеют одинаковую архитектуру и используют одно и то же ядро. Инструкции по компоновке GPFS PL можно найти в файле /usr/lpp/mmfs/src/README . Для нашего примера кластера процедура состоит из следующих действий:


      Выполните экспорт SHARKCLONEROOT=/usr/lpp/mmfs/src .


    • #define GPFS_LINUX
    • #define GPFS_ARCH_X86_64
    • LINUX_DISTRIBUTION = REDHAT_AS_LINUX
    • #define LINUX_DISTRIBUTION_LEVEL 34
    • #define LINUX_KERNEL_VERSION 2042127

    • tracedev
    • mmfslinux
    • lxtrace
    • dumpconv

    В данном примере GPFS-кластер создается при помощи нескольких отдельных действий. Хотя все они не являются необходимыми, это хороший метод работы с различными типами узлов в кластере (узлами системы хранения данных или другими).

    Первый шаг — создание кластера, содержащего только узлы системы хранения данных и узел кворума: всего пять узлов. Используйте файлы дескрипторов узла при создании кластера, которые содержат краткое имя хостов интерфейса системы хранения данных всех включаемых узлов, за которым указывается следующая информация:


      Manager или client: Определяет, должен ли узел формировать часть пула, из которого извлекаются менеджеры конфигурации и файловой системы. Пример кластера в этом пуле содержит только узлы хранения данных.

    Для создания кластера используется следующая команда:

    mmcrcluster -n stor.nodes -C gpfs1 -p stor001_s -s stor002_s -r /usr/bin/ssh -R /usr/bin/scp

    Ниже приведен файл-дескриптор узла stor.nodes , используемый в примере:

    stor001_s:manager-quorum stor002_s:manager-quorum stor003_s:manager-quorum stor004_s:manager-quorum quor001_s:client-quorum

    Используйте записи, аналогичные _s:client-nonquorum , на более поздних шагах для всех остальных узлов, добавляемых в кластер, таких как вычислительные узлы, пользовательские узлы и управляющие узлы.

    Следующим действием является разрешение параметра unmountOnDiskFail на узле разрешения конфликтов с использованием команды mmchconfig unmountOnDiskFail-yes quor001_s . Это предотвращает выдачу отчета о ложных дисковых ошибках менеджеру файловой системы.

    Следующим действием является создание дисков, используемых GPFS, при помощи команды mmcrnsd –F disc#.desc . Выполнение этой команды создает глобальное имя для каждого диска, что является необходимым шагом, поскольку диски могут иметь различные имена /dev на каждом узле в GPFS-кластере. Выполните эту команду на всех дисках, используемых для файловой системы GPFS. На данном этапе определите первичный и вторичный NSD-серверы для каждого диска; они используются для операций ввода/вывода (I/O) от имени NSD-клиентов, не имеющих локального доступа к системе хранения данных SAN.

    Флаг -F используется для указания файла, содержащего дескрипторы диска для дисков, определяемых как NSD. Для удобства обслуживания в примере кластера выполните этот процесс один раз на LUN, представленных каждой системой DS4500, и один раз на диске сервера разрешения конфликтов. Каждый массив или LUN на каждой системе DS4500 имеет дескриптор в используемых файлах. Ниже приведен пример строки из disk1.desc :

    sdc:stor001_s:stor002_s:dataAndMetadata:1:disk01_array01S

    Ниже перечислены поля данной строки по порядку:


      Имя локального диска на первичном NSD-сервере

    Используя описанные выше файлы, определите следующие три аварийные группы в конфигурации:


      Диски в первом контроллере DS4500, то есть disk01 .

    Следующий шаг — запуск GPFS-кластера путем выполнения следующих действий:


      Запустите GPFS на всех NSD-серверах одновременно для предотвращения маркировки NSD как находящихся в неактивном состоянии. Используйте следующую команду: mmstartup -w stor001_s,stor002_s,stor003_s,stor004_s .

    Этот метод может показаться чрезмерно предусмотрительным, но он выбран в качестве масштабируемого метода, который будет работать для очень большого кластера. Альтернативой указанному выше методу является использование команды mmstartup –a . Это работает для кластеров меньшего размера, но может пройти немало времени до возврата из команды для большого кластера, в котором узлы могут быть недоступны по различным причинам, например, при проблемах в сети.

    Для примера создается одна большая файловая система GPFS с использованием всех NSD, определенных для GPFS. Обратите внимание на то, что использованная команда, в отличие от указанной выше команды mmcrnsd , принимала в качестве аргумента измененные файлы дескрипторов дисков. Это требует объединения в один файл информации, выводимой на каждом шаге при создании NSD.

    Пример кластера использует следующие настройки:


      Все NSD (устанавливается при помощи -F ).

    Вот полная команда:

    mmcrfs /gpfs /dev/gpfs -F disk_all.desc -A yes -B 256K -m 2 -M 2 -r 2 -R 2 -n 1200 -Q yes

    В первый раз после создания /gpfs она монтируется вручную. Затем, с разрешенным параметром automount, она монтируется автоматически при запуске узлом GPFS.

    Флаг -Q в приведенной выше команде mmcrfs разрешает использование квот (quotas) в файловой системе /gpfs . Квоты могут быть определены для отдельных пользователей или групп пользователей. Устанавливается также уровень квот по умолчанию, который применяется к каждому новому пользователю или группе. Квоты по умолчанию включаются при помощи команды mmdefquotaon . Изменяются квоты по умолчанию при помощи команды mmdefedquota . Эта команда открывает окно редактора, в котором можно указать их границы. Ниже приведен пример установки границ для квот:

    gpfs: blocks in use: 0K, limits (soft = 1048576K, hard = 2097152K) inodes in use: 0, limits (soft = 0, hard = 0)

    Можно изменить отдельные квоты для пользователя или группы, используя команду mmedquota –u . Пользователь может отобразить свою квоту при помощи команды mmlsquota . Пользователь superuser может отобразить состояние квот файловой системы при помощи команды mmrepquota gpfs .

    Данный кластер настроен так, чтобы GPFS запускался автоматически при каждой начальной загрузке сервера, путем добавления записи в /etc/inittab при помощи команды mmchconfig autoload=yes .

    Используйте pagepool (пул страницы) GPFS для кэширования данных пользователя и метаданных файловой системы. Механизм pagepool позволяет GPFS реализовать запросы на чтение (а также запись) асинхронно. Увеличение размера pagepool увеличивает объем данных или метаданных, которые GPFS может кэшировать, не требуя синхронных операций ввода/вывода. Значением по умолчанию для pagepool является 64 MB. Максимальное значение GPFS pagepool равно 8 GB. Минимальное разрешенное значение равно 4 MB. На Linux-системах максимальный размер pagepool равен половине физической памяти компьютера.

    Оптимальный размер pagepool зависит от требований приложения и эффективного кэширования его данных, к которым производится повторный доступ. Для систем с приложениями, обращающимися к большим файлам, повторно использующим данные, использующим преимущества функциональности GPFS предвыборки (prefetching) данных или работающим по схеме случайных операций ввода/вывода, увеличение значения pagepool может повысить эффективность. Однако, если значение слишком велико, GPFS не запустится.

    Для нашего примера кластера используйте значение pagepool 512 MB для всех узлов в кластере.

    Для оптимизации производительности сети и, следовательно, GPFS, разрешите jumbo-фреймы путем установки размера MTU для адаптера сети хранения данных в 9000. Оставьте параметр /proc/sys/net/ipv4/tcp_window_scaling разрешенным, поскольку это настройка по умолчанию. Настройки TCP-окна подгоняются при помощи CSM-сценариев во время установок, добавляющих следующие строки в файл /etc/sysctl.conf как на NSD-серверах, так и на NSD-клиентах:

    # увеличить границы TCP-буфера Linux net.core.rmem_max = 8388608 net.core.wmem_max = 8388608 # увеличить максимальные размеры и размеры по умолчанию TCP-буфера Linux net.ipv4.tcp_rmem = 4096 262144 8388608 net.ipv4.tcp_wmem = 4096 262144 8388608 # увеличить max backlog, чтобы избежать пропущенных пакетов net.core.netdev_max_backlog=2500

    Настройки кэша сервера хранения данных при неправильной их установке могут повлиять на производительность GPFS. Пример использует следующие настройки контроллеров DS4500, рекомендованные в документации по GPFS:

    • Read cache: enabled
    • Read ahead multiplier: 0
    • Write cache: disabled
    • Write cache mirroring: disabled
    • Cache block size: 16K

    Все! Вы должны были успешно установить большой Linux-кластер, следуя примеру из данной серии статей. Примените эти принципы для успешной установки вашего собственного большого Linux-кластера.

    • Установка большого Linux-кластера, часть 1: Введение и аппаратная конфигурация.
    • Установка большого Linux-кластера, часть 2: Конфигурирование управляющего сервера и установка узла.
    • Установка большого Linux-кластера, часть 3: Система хранения данных и файловые системы с совместным доступом

    • Web-страница IBM TotalStorage DS4500.
    • Страница поддержки IBM DS4500.

    • Общая страница продукта IBM EXP710.
    • Страница поддержки IBM EXP710.

    • Общая страница продукта IBM SAN Switch H16.
    • Страница поддержки IBM SAN Switch H16.

    Получить продукты и технологии


      Последняя версия Storage Manager для вашего оборудования на странице файлов для загрузки DS4500.

    Грэхэм Уайт фото

    Грэхем Уайт (Graham White) работает специалистом по системному управлению Linux Integration Centre в отделе Emerging Technology Services офиса IBM Hursley Park в Великобритании. Он имеет сертификат Red Hat Certified Engineer и специализируется на широком спектре технологий с открытым исходным кодом, открытых стандартах и технологиях IBM. В сферу его интересов входят LAMP, Linux, системы защиты, кластеризация и все аппаратные платформы IBM. Получил степень бакалавра по вычислительной технике и управлению с отличием в Exeter University в 2000 году.

    Gpfs что это такое

    Продолжение. Начало здесь.

    IBM Spectrum Scale

    IBM Spectrum Scale – это решение, созданное на основе файловой системы IBM General Parallel File System (GPFS), способно масштабировать ёмкость и производительность для аналитических систем, репозиториев контента и других задач.

    Когнитивные механизмы IBM Spectrum Scale умеют распределять данные среди различных устройств хранения, тем самым оптимизируя использование доступной емкости, упрощая администрирование и обеспечивая высокую производительность. IBM Spectrum Scale поддерживает глобального пространства имен с универсальным доступом, которое объединяет современные средства для работы с файлами, размещенных в сетевых файловых системах (NFS), блочные хранилища и серверы со встроенными хранилищами данных большого объема. Файловая система IBM Spectrum Scale может использоваться для работы с файлами (POSIX, NFS, CIFS), объектами (S3, SWIFT) и распределенной файловой системой Hadoop (HDFS) при решении задач анализа больших данных на месте хранения.

    Задачи и возможности IBM Spectrum Scale.

    Свойства IBM Spectrum Scale

    Хорошая масштабируемость, которая позволяет обеспечивать максимальную пропускную способность и минимальные задержки при доступе.

    Аналитика с учетом данных, которая позволяет автоматически переносить данные на оптимальный уровень хранения (флеш, диск, кластер, лента), что позволяет до 90% снизить расходы на архивирование данных.

    Автоматическое размещение данных по уровням в файловой системе IBM Spectrum Scale.

    Распределённость, то есть, возможность доступа к данным из любого места, ускоряет работу приложений по всему миру, за счёт технологии распределённого кэширования и активного управления файлами.

    Безопасность данных, технологии идентификация, шифрования, защиты Erasure Coding и репликации позволяют достичь соответствия регулятивным требованиям.

    Универсальность, единое решение для управления масштабируемым хранилищем данных, обеспечивающее унификацию виртуализации, поддержки аналитических сред, обработки файлов и объектов.

    Прозрачные политики хранения делают возможным сжатие и многоуровневое хранение данных на ленточных накопителях или в облаке, с целью сокращения расходов. Размещение данных с учетом места их использования уменьшает задержки и увеличивает производительность работы с данными.

    Интеллектуальное кэширование данных, технология Active File Management (AFM) распространяет глобальное пространство имен Spectrum Scale за пределы географических границ, обеспечивая высокую производительность при чтении и записи данных и автоматическое управление пространством имен. Данные записываются или изменяются локально и в других местах эти данные получают с минимальной задержкой.

    Графический интерфейс IBM Spectrum Scale GUI обеспечивает простое администрирование объёмов данных уровня петабайт различных типов: файловых, объектных или блочных.

    IBM Spectrum Scale – это хорошо зарекомендовавшее себя масштабируемое решение по администрированию данных, которое ранее называлось GPFS (General Parallel File System). Начиная с версии 4.1, это решение называется Spectrum Scale. Однако, версии до 4.1 будут поддерживаться под старым названием GPFS.

    Основные характеристики

    • Практически неограниченный объём хранения данных до нескольких йоттабайт и до девяти квинтиллионов файлов.
    • Высокая производительность более 400 ГБ/с, и одновременный доступ к общим наборам данных из нескольких доменов пользователей.
    • Программно-конфигурируемая СХД, которая позволяет:
      • масштабирование на относительно недорогом коммерчески доступном оборудовании COTS (Commercial Of The Shelf), при обеспечении возможностей управления хранением данных с их высокой доступностью;
      • использование любых комбинаций носителей: флеш-накопителей, дисков и лент;
      • использование различных моделей кластеров, которые включает SAN (storage area networks), Network Shared Disk, и кластеры Shared Nothing;
      • добавление ёмкости без влияния на работу запущенных приложений.

      Применения

      Spectrum Scale используется уже более 15 лет во многих отраслях экономики во всём мире, и в таких областях, требовательных к объёму и производительности обработки данных, как:

      • Инженерный дизайн;
      • Медиа и СМИ(радио и ТВ, контент провайдеры);
      • Нефтегаз: обработка и аналитика данных сейсморазведки;
      • Умные города: видеонаблюдение и видеоаналитика;
      • Автомобили: краштесты, системы помощи водителю и беспилотные автомобили;
      • Оборона и авиация (запись полётных данных);
      • Архивация спутниковых изображений;
      • Телеком: хранение данных вызовов CDR (Call detail records);
      • Банкинг и финансовый сектор: отчётность, обработка чековых данных;
      • Бизнес-аналитика (Business intelligence);
      • Поиск и сопоставление нужной информации в массивах данных (Data mining);
      • Научные исследования;
      • Когнитивные приложения Интернета Вещей, такие как IBM Watson™.

      Функциональные возможности

      • Увеличение эффективности использования ресурсов за счёт объединения в пулы изолированных ранее ресурсов.
      • Интеллектуальное использование ресурсов и автоматизация администрирования СХД снижает стоимость хранения и повышает операционную эффективность, возможности автоматизации политик уровневого хранения.
      • Разнообразные возможности конфигурации для оптимизации производительности, гибкости и надёжности, устранения отказов типа «single point-of-failure», а также автоматизации операций для быстрой замены отказавшего диска или устранения сбоя сервера.
      • Катастрофоустойчивость за счет возможности работы на множестве распределённых сайтов, подключенных к локальному кластеру Spectrum Scale (Disaster Recovery).
      • Кросс-платформенное решение, которое может работать на многих операционных системах. Кластеры Spectrum Scale можно создавать на узлах AIX, Linux и Windows server, причем в одной системе могут работать все три ОС (а также на IBM System Z®).
      • Оперативность реакции на события и появление новых требований, быстрое развёртывание необходимых ресурсов.

      Основные компоненты системы

      • Кластер (Cluster). Кластер состоит из нескольких узлов, а также общих сетевых дисков NSD (network shared disks). Он может быть сконфигурирован в серверном репозитории (конфигурационной базе данных), где хранятся файлы конфигурации кластера. При конфигурации кластеру должен быть назначен первичный и вторичный сервер. Начиная с версии 4.1, используется новый тип репозитория, который называется «конфигурационный репозиторий кластера» CCR (Cluster Configuration Repository). Здесь автоматически поддерживаются конфигурационные файлы для всех узлов.
      • Узел (Node). Узел – это любой сервер, на котором установлено ПО Spectrum Scale, с прямым или сетевым доступом к другому узлу. В зависимости от типа доступа, каждый узел может иметь различную роль внутри кластера.
      • Менеджер кластера (Cluster manager). Узел менеджера кластера отвечает за правильность операций на всех узлах и всего узла в целом. Он выполняет следующие задачи:
        • Мониторинг выделения дисков
        • Обнаружение ошибок и восстановление при отказе узла внутри кластера
        • Определение кворума узлов и разрешение на старт домену Spectrum Scale и продолжение использования файловой системы
        • Обработка информации о конфигурации и информирование узлов в удалённых кластерах об изменениях конфигурации
        • Выбор узла для менеджера файловой системы.
      • Менеджерфайловойсистемы(File system manager). Этот менеджер поддерживает информацию о доступности дисков в файловой системе. В большом кластере для менеджера файловой системы может понадобиться отдельный узел. Менеджер файловой системы выполняет следующие функции:
        • Управляет конфигурацией файловой системы;
        • Управляет выделением дискового пространства;
        • Управляет конфигурациями квот;
        • Поддерживает сервисы безопасности.
      • Общийсетевойдиск(NSD, Network shared disk). Используется для глобального пространства имён и доступа к данным кластера. Если все узлы не имеют прямого подключения к дискам (например, в среде SAN), то NSD должен быть определён как первичный сервер, причём рекомендуется, чтобы вторичный сервер тоже был определён. Затем ввод-вывод производится через сетевое подключение сервера NSD, который выполняет ввод-вывод от имени запрашивающего узла. Даже если все NSD подключены к дискам, рекомендуется определять серверы NSD, чтобы, в случае потери доступа первичного сервера к физическим дискам, существовал запасной маршрут.
      • Пул накопителей (Storage pool). Это комплект NSD, использующихся для партиции пространства хранения, по принципу общих параметров, таких как производительность, доступность в местной сети и надёжности. Использование пулов накопителей в Spectrum Scale позволяет группировать устройства хранения по параметрам производительности, локальности или надёжности внутри файловой системы.
      • Блок (Block). Блок – это наибольший элемент для операций ввода-вывода и выделения дискового пространства в файловой системе Spectrum Scale. Размер блока указывается при создании файловой системы и определяет полосу пропускания при распределении данных по дискам. Spectrum Scale поддерживает размер блока от 16 кбайт до 16 Мбайт. По умолчанию размер блока составляет 256 кбайт в предыдущей версии GPFS и 64 кбайт при использовании Spectrum Scale в версии 4.1.0.4. Spectrum Scale допускает различные размеры блоков для метаданных и самих данных, если диски для данных и метаданных разделены.
      • Чанк (Chunk). Термин «чанк» относится к функции оптимизации размещения файла File Placement Optimizer (FPO) файловой системы Spectrum Scale. Чанк – это логическая группа блоков, которая ведет себя как один большой блок. Множитель блоков в группе (block group factor) используется FPO при определении числа блоков, образующих чанки на дисках, присоединённых к узлу. Затем чанк предписывается всем доступным дискам внутри узла. Размер чанка определяется умножением размера блока на множитель блоков группы. Этот множитель может лежать в пределах от 1 до 1024. Значение множителя по умолчанию равно 1, с целью совместимости со стандартными файловыми системами Spectrum Scale. Установка размера блока в 1 МБ и множителя блоков группы в 128 даёт в результате размер чанка 128 МБ.
      • Группа отказа (Failure group). Группа отказа – это набор дисков, образующих общую точку отказа (common point of failure). То есть любой отказ в такой группе дисков может вызвать одновременную недоступность их всех. При создании многочисленных реплик определённого блока, Spectrum Scale использует информацию о группах отказов, чтобы обеспечить то, что никакие две парные реплики блоков данных не будут размещаться в одной и той же группе отказа. Группа отказа может быть определена как набор до трёх чисел, разделённых запятыми, которая даёт возможность определить топологию группы.
      • Мета-узел (Metanode). Узел, обрабатывающий метаданные, которые также называются «модификациями блока директории» (“directory block updates”).
      • Метаданные (Metadata). Содержит информацию о конфигурации определённого кластера и данные, не относящиеся к пользователю (non-user data).
      • Узел приложений (Applicationnode). Монтирует файловую систему Spectrum Scale и запускает пользовательские приложения, получающие доступ к файловой системе.
      • Кворумный узел (Quorum nodes). Это узлы, поддерживающие активность кластера Spectrum Scale. Есть два типа узлов кворума кластера:
        • Nodequorum, где кластер поддерживается рабочим, когда доступны большинство узлов кворума.
        • Node quorum with tiebreaker disks, где кластеры активны при хотя бы одном кворумном узле и он имеет доступ к дискам, которые определены как tiebreaker disks.

      Три NSD, определённые как диски tiebreaker disk для кворумных узлов (источник: IBM).

      • Топология кластера. Топологию IBM Spectrum Scale можно гибко конфигурировать под различные решения для пользователя. Четыре основных типовых конфигурации Spectrum Scale, используемых в зависимости от местоположения приложений на узлах кластера:
        • Приложения, работающие только на NSD клиентов Spectrum Scale
        • Приложения, работающие на узлах с СХД с прямым подключением
        • Приложения, работающие на серверах с подключёнными NSD
        • Приложения, работающие на кластере FPO (File Placement Optimizer)

        Три редакции Spectrum Scale

        Есть три разных редакции (Edition) Spectrum Scale:

        • Express Edition: базовая функциональность Spectrum Scale.
        • Standard Edition: технический эквивалент GPFS 3.5, включает базовые функции, а также Information Lifecycle Management, Active File Management и Clustered NFS.
        • Advanced Edition: к функциям Standard Edition добавлена функция шифрования.

        Продолжение следует

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *