Targetcli fb настройка debian
Обновлено: 25.06.2024
Изучая разные методы повышения производительности работы СУБД SQL Server, добрался до такой интересной темы, как использование RAM-диска для размещения файлов нагруженной системной базы данных tempdb. Выяснил для себя то, что из работоспособных свободно-распространяемых инструментов для организации RAM-диска под ОС Windows Server на текущий момент многие выделяют утилиту imDisk Toolkit. Однако этот инструмент, как и прочие его аналоги, не получится использовать в кластерных конфигурациях SQL Server, где использование ресурсов оперативной памяти (далее ОЗУ) в любой момент времени может быть переключено с одного кластерного узла на другой. То есть, если и использовать в кластере RAM-диск, то он должен быть одинаково доступен всем узлам кластера, как и любой другой кластерный диск, участвующий в конфигурации кластеризованного экземпляра SQL Server.
Напрашивающимся в таком случае решением может стать использование в качестве RAM-диска ОЗУ не самих узлов кластера, а ОЗУ стороннего хоста, подключенного к узлам кластера в качестве дискового устройства через транспорт Fiber Channel SAN (как отличающийся приемлемыми показателями задержки). То есть на выделенном хосте используются локальные ресурсы ОЗУ для создания RAM-диска, после чего RAM-диск транслируется на узлы кластера через FC SAN, как блочное устройство, и может использоваться в качестве кластерного диска.
Далее я опишу пример создания такого RAM-диска на выделенном хосте с ОС Debian GNU/Linux 9 и его трансляцию в SAN с помощью Linux-IO (LIO). На сервере для обеспечения работы FC Target предварительно установлен контроллер FC HBA QLogic и задействован специальный режим работы драйвера – Target Mode.
Обязательным условием в нашем примере является то, что на Linux-хосте нужно организовать механизм сохранения данных RAM-диска при выключении ОС и восстановлении данных на RAM-диск при включении ОС с использованием выделенного SSD-диска.
Настраиваем RAM-диск на Linux
Перейдём на наш Linux-сервер, имеющий большой объем оперативной памяти, часть которой мы готовы выделить под организацию RAM-диска.
Создаём каталог для RAM-диска и каталог для хранения резервной копии содержимого RAM-диска:
Форматируем отдельный SSD диск для сохранения/восстановления данных RAM-диска при выключении/включении хостовой ОС Linux:
Проверяем монтирование созданного на SSD диске раздела в каталог для хранения резервной копии:
Обратите внимание на то, что свободное место в каталоге /mnt/ramdisk1-backup всегда должно быть не меньше, чем размер планируемого содержимого RAM-диска. В противном случае мы можем столкнуться с ситуацией, при которой окажется невозможно сохранить данные RAM-диска при выключении сервера, что приведёт к потере всех данных на этом RAM-диске.
Выясним идентификатор UUID SSD-диска:
В конец системного конфигурационного файла /etc/fstab добавляем директивы монтирования RAM-диска и диска для хранения в соответствующие каталоги:
При описании директивы создания RAM-диска нам желательно сразу правильно спланировать его размер, учитывая то, что размер диска должен быть немного больше, чем объём планируемого блочного устройства. Это нужно для того, чтобы в дальнейшем избежать сигнализации систем мониторинга о том, что исходный RAM-диск переполнен. Например, в нашем случае в fstab при запуске системы создаётся RAM-диск размером 30725MB, а на этом диске мы в последующем будем создавать файл размером 30720MB, который и будет в дальнейшем транслироваться в виде блочного устройства из LIO в SAN.
Настраиваем службу lio-config-controller
Создадим скрипт, который будет представлять собой основу для работы специальной службы systemd, которую мы назовём, например, lio-config-controller.service. Эта служба будет управлять запуском и остановкой блочного устройства, транслируемого в SAN через конфигурацию LIO.
Наполним скрипт содержимым:
Как видно, скрипт может работать в двух основных режимах:
1) Запуск c ключом start
В этом режиме скрипт будет размещать на уже доступном в системе RAM-диске в каталоге /mnt/ramdisk1 специальный файл ramdisk1.img . При этом img-файл будет вновь создаваться только в том случае, если его предыдущая копия не обнаружена на SSD-диске в каталоге /mnt/ramdisk1-backup . В случае обнаружения копии img-файла на SSD, эта копия будет восстанавливаться на RAM-диск. В дальнейшем img-файл на RAM-диске будет загружаться в конфигурацию LIO, создавая FC Target. Обратите внимание на то, что перед загрузкой новой конфигурации, текущая конфигурация LIO будет очищаться.
2) Запуск c ключом stop
В этом режиме конфигурация LIO очищается, то есть из системы удаляется FC Target, ассоциированный с img-файлом на RAM-диске. После чего происходит сохранение img-файла из RAM-диска на SSD-диск.
Оба режима работы скрипта логируют основные этапы выполняемых операций в отдельный log-файл.
Сделаем скрипт исполняемым:
Так как наш скрипт предполагает наличие в системе уже смонтированных дисков, перед его вызовом мы должны удостовериться в том, что эти диски действительно смонтированы. Оформим вызов скрипта, как службы systemd, таким образом, чтобы у службы (юнита) lio-config-controller.service была зависимость от юнитов, отвечающих за монтирование соответствующих дисков.
Выясним то, какие имена имеют автоматически генерируемые юниты монтирования интересующих нас дисков:
Как видим, в нашем случае юниты имеют имена " mnt-ramdisk1.mount " и " mnt-ramdisk1\x2dbackup.mount ".
Создадим новый юнит lio-config-controller.service, который будет выполнять наш скрипт, загружая и останавливая тем самым конфигурацию LIO. При этом не забудем выставить зависимость от юнитов монтирования нужных нам дисков.
Наполним конфигурацию юнита следующим образам:
Так как в процессе остановки службы может потребоваться некоторое время на операцию сброса содержимого RAM-диска на SSD, дополнительно добавим таймаут ожидания остановки службы. Разумеется, если вместо SSD для хранения используется более медленный HDD, имеет смысл увеличить этот таймаут. В нашем случае этот таймаут составляет 300 секунд или 5 минут. При использовании SSD-диска величину таймаута можно сделать и ниже. Для расчёта оптимальной величины можно использовать фактическое время, затрачиваемое на сохранение содержимого RAM-диска, которое фиксируется скриптом в логе /var/log/script_lio-config-controller.log .
Включаем автоматическую загрузку созданного нами юнита в конфигурации systemd:
В опорном скрипте созданной нами службы lio-config-controller используется утилита targetcli, которая позволяет нам управлять конфигурацией LIO. Из официальных репозиториев Debian Linux установим пакет targetcli-fb, позволяющий работать с LIO в Debian и содержащий соответствующую утилиту:
Так как загрузкой и выгрузкой конфигурации LIO у нас будет заниматься собственная служба, нам потребуется остановить и отключить автоматический запуск стандартной службы rtslib-fb-targetctl, устанавливаемой в систему из пакета targetcli-fb. Вся ранее настроенная конфигурация LIO при этом будет очищена.
После всех проделанных изменений можно перезагрузить конфигурацию служб systemd:
Теперь можно выполнить проверку того, как в автоматическом режиме отрабатывает созданная нами конфигурация при выключении и включении хостовой ОС Linux.
Базовая проверка и отладка
Перезагружаем сервер и после завершения загрузки ОС проверяем то, что созданная нами служба lio-config-controller успешно запущена:
Дополнительно можно проверить то, в какой последовательности отработал запуск служб systemd в процессе запуска ОС Linux. Для этого нам потребуется включить и настроить службу journald, как это описано в статье "Включение режима сохранения логов служб systemd через journald в Linux". После соответствующей настройки системы можно посмотреть логи интересующих нас служб, связанных с монтированием дисков, на предмет времени их запуска и остановки:
Основные этапы работы скрипта, вызываемого службой lio-config-controller можем посмотреть в логе, который указан в самом начале скрипта:
Проверяем то, что LIO загружен именно в той конфигурации, что мы описали в скрипте
Как видно из нашего примера, ранее обозначенная в скрипте конфигурация LIO успешно загружена и созданы цели FC Target.
После этого настраиваем зонирование на оптических коммутаторах SAN, чтобы на серверах на базе Windows Server стал доступен соответствующий FC Target.
В нашем случае презентованный LUN доступен на обоих узлах кластера Windows Server по двум путям, обеспечивая тем самым повышенную доступность и производительность. Получившееся общее для двух Windows-систем дисковое устройство форматируем в NTFS и добавляем в кластер в качестве общего кластерного диска.
Теперь настало время убедиться в том, что в случае возникновения необходимости отключения Linux-сервера, предоставляющего свою оперативную память, всё содержимое кластерного диска будет сохранено.
Проверка сохранения содержимого RAM-диска
Для проверки создаём на кластерном диске Windows Server какие-то файлы и запоминаем их содержание, то есть копируем туда какой-то осмысленный контент. После этого выводим в кластере диск в режим обслуживания или просто переводим в состояние Offline, чтобы избежать кластерных попыток активировать диск на соседнем узле кластера в тот момент, когда мы отключим для проверки Linux-сервер.
После этого перейдём на Linux-сервер и вызовем выключение его ОС штатным способом. В ходе завершения работы ОС обращаем внимание на то, что таймаут остановки службы lio-config-controller используется именно тот, который мы указали в настройках юнита systemd - lio-config-controller.service:
После проверочного отключения снова включаем Linux-сервер и дожидаемся успешного запуска ОС, инициализации RAM-диска (с восстановлением данных из копии на SSD диске) и его последующей трансляции в конфигурацию LIO. После того, как всё "взлетело", можем снова проанализировать лог работы службы lio-config-controller и лог работы самого скрипта на предмет корректности этапов выключения/включения RAM-диска при выключении/включении ОС:
Все операции должны отрабатывать последовательно и без ошибок. И здесь лучше не жалеть времени на скрупулёзную проверку корректной и своевременной отработки каждого этапа. Только так можно рассчитывать на то, что данные с RAM-диска не будут в дальнейшем потеряны.
Когда все проверки на стороне Linux-сервера закончены, вернёмся в консоль управления кластером Failover Cluster Manager и убедимся в том, что кластерный RAM-диск работоспособен и успешно переводится в состояние Online. После успешного возобновления работы кластерного диска проверим его содержимое и убедимся в том, что на диске присутствуют скопированные нами ранее на этот диск файлы.
Проверка производительности RAM-диска
Сразу сделаем оговорку о том, что любые сравнительные тесты на проверку производительности всегда зависят от множества факторов. И в каждом отдельно взятом случае и отдельном рабочем окружении эти факторы могут иметь разную степень влияния на конечный результат. Поэтому в нашем конкретном случае никто не претендует на какую-то объективность. Мы лишь поделимся одним простым наблюдением.
На два рассматриваемых в нашем примере сервера с ОС Windows Server помимо RAM-диска через FC SAN (два линка FC 4G c MPIO) презентовано ещё несколько дисковых устройств, одно из которых представляет собой массив RAID10 из 12 SSD дисков Intel SATA 3G с СХД HP MSA P2000 G3. При тестировании такого дискового устройства на любом из узлов кластера получались примерно следующие пиковые показатели:
При тестировании на этих же серверах нашего RAM-диска получались следующие пиковые показатели:
Небольшое отклонение в показателях чтения в пользу СХД MSA можно попытаться объяснить опять же разными факторами, но не будем заострять на этом внимание. Внимание здесь стоит обратить на ощутимую разницу в показателях записи. При операциях с большими блоками, начиная с 512KB, на лицо выигрыш RAM-диска и по второму графику видно, что на каком-то уровне (возможно FC HBA на Linux-сервере, возможно на SAN …) просто срабатывает ограничение, и нельзя исключать того, что есть возможность улучшить полученные показатели чтения/записи. Кстати, обратите внимание также и на ощутимую разницу по показателям чтения/записи при работе с блоками 64K (рекомендуемый Microsoft размер блока при форматировании накопителей под файлы БД SQL Server).
Таким образом, привнесённый в кластер RAM-диск, в качестве места размещения файлов нагруженной системной базы данных tempdb кластеризованного экземпляра СУБД SQL Server, представляется вполне привлекательным решением.
Замечание о последовательности выключения и выключения серверов
Следует обратить внимание на то, что в случае возникновения нештатных ситуаций в ЦОД, например, в случае отключения электропитания, порядок автоматического отключения серверов должен быть настроен таким образом, чтобы физический Linux-сервер c RAM-диском выключался только после того, как завершат свою работу узлы кластера, которые используют этот RAM-диск в качестве кластерного ресурса.
Ну и, разумеется, обратного принципа следует придерживаться в процессе включения серверов. То есть Linux-сервер с RAM-диском должен запускаться, так же как и прочие СХД, раньше, чем стартуют серверы-узлы кластера Windows, использующие этот RAM-диск.
Заключение
Стоит отметить тот факт, что организацию RAM-диска описанным здесь методом можно выполнить не только на ОС Debian GNU/Linux 9, но и на других дистрибутивах Linux. А в качестве механизма трансляции RAM-диска в FC SAN можно использовать не только Linux-IO, но и такой замечательный инструмент, как SCST, пример использования которого мы уже рассматривали ранее.
Если же говорить о том, с чего мы начали, то, разумеется, можно поспорить о плюсах и минусах использования RAM-диска для системной базы данных tempdb СУБД SQL Server, равно как и об описанной здесь организации RAM-диска, как таковой. Здесь каждый для себя выводы делает сам исходя из своего практического опыта и степени "избалованности"
Немного теории
Targetcli на CentOS 7 представляет таргет в виде иерархически построенной структуры. И делит таргет на back-end и front-end части. Backstores – это back-end, fabric module – это front-end. Backstores это всегда один раздел в иерархии targetcli, внутри которого отображаются хранилища в виде объектов, в то время, как fabric module может быть не один, в нём содержатся различные настройки видимой снаружи части таргета. Существует несколько типов fabric module: Fibre Channel over Ethernet (FCoE), Fibre Channel, IEEE 1394, iSCSI, iSCSI Extensions for RDMA (iSER), SCSI RDMA Protocol (SRP), USB Gadget, Loopback. Ниже можно видеть как выглядит структура таргета с точки зрения targetcli:
Теперь по порядку по элементам
Backstores – это раздел, в котором отображаются объекты-хранилища. Backstores не видимая снаружи часть iSCSI таргета.
Block –жесткий диск, символические ссылки на диск или LVM.
PSCSI (SCSI pass-through) – любое устройство для хранения информации, поддерживающее SCSI команды напрямую, то есть без эмуляции SCSI. Этот бэкстор не нужно использовать, так как может привести к повреждениям железа.
iSCSI – это fabric module, видимая снаружи часть iSCSI таргета. Он содержит список таргетов, лунов, права доступа и т.п. Список всего этого добра появится после настройки.
Loopback – ещё один fabric module, который дает доступ к таргету локально.
Создание iSCSI таргета на linux с помощью targetcli
- Для начала необходимо установить targetcli
- Сделать доступным демона (службу) target и запустить его
- Открыть targetcli и посмотреть иерархию, в виде которой представлен таргет, почитать помощь. Помощь можно вызывать в любом разделе внутри targetcli, везде будут свои команды.
- Создать блочное устройство в бэксторе. В первом случае создано устройство на основе непосредственно жесткого диска, затем добавлено устройство на основе LVM, что гораздо удобнее в эксплуатации.
На этом таргет готов к использованию. Остается только подключиться инициатором к таргету и использовать LUN как локальный жесткий диск.
Протокол iSCSI получил широкое распространение как простой и недорогой способ организации сетей хранения данных (SAN) поверх обычных Ethernet-сетей. iSCSI не требует приобретения дополнительного оборудования и существенного изменения инфраструктуры, тем не менее позволяя более эффективно использовать пространство в хранилищах и увеличить надежность хранения данных. В данном материале мы рассмотрим создание iSCSI-хранилища в среде современных ОС семейства Debain или Ubuntu, включая многочисленные их производные.
Начиная с Debian 9 Stretch и Ubuntu 18.04 LTS пакет iSCSI Enterprise Target (iscsitarget) был удален и ему на смену пришел Linux SCSI target (tgt), работу с которым мы и будем рассматривать. Все указанные ниже команды следует вводить с правами суперпользователя или используя sudo. В нашем случае использовалась OC Debian 10, но все сказанное будет справедливо для любого основанного на нем дистрибутива, а с некоторыми поправками для любых Linux-систем.
Прежде всего установим Linux SCSI target, не забыв перед этим обновить список пакетов:
Серверная часть в iSCSI называется порталом, который содержит цели (таргет, Target), каждая из которых предоставляет клиенту - инициатору (Initiator) доступ к одному или нескольким блочным устройствам. В качестве блочных устройств могут использоваться физические диски, логические тома, файлы (виртуальные диски) и т.д. и т.п. В нашем примере мы будем использовать файл. На наш взгляд это наиболее удобно, так как позволяет достаточно гибко управлять системой хранения - файлы виртуальных дисков можно легко перемещать между серверами или физическими дисками, а также управлять их размерами.
Виртуальные диски могут иметь фиксированный размер или быть динамическими. Диск фиксированного размера сразу занимает все выделенное пространство, но при этом обеспечивает наиболее высокое быстродействие и практически не подвержен фрагментации. Динамический диск увеличивает свой размер по мере записи на него данных, файл диска при этом может фрагментироваться, особенно если активная запись ведется сразу в несколько таких дисков.
Какой же тип выбрать? Здесь все зависит от решаемых задач, если вы заранее знаете объем хранимых данных, и он не будет существенно изменяться - то выбирайте диск фиксированного размера, в иных случаях более предпочтителен динамический диск, как позволяющий более оптимально использовать дисковое пространство.
Для хранения файлов виртуальных дисков мы будем условно использовать директорию /storage, поэтому вам потребуется откорректировать пути в соответствии с реальным расположением данных.
Для создания диска фиксированного размера используйте команду:
Она создаст файл размером 2 ГБ, так как мы указали размер блока - bs - равным 1 MБ и количество таких блоков - count - 2048.
Для создания динамического диска:
Данная команда создает разреженный файл с максимальным размером 200 ГБ, разреженными называются файлы, которые вместо последовательности нулей на диске хранят информацию об этих последовательностях в специальной таблице.
Для преобразования обычного файла в разреженный выполните команду:
Где filename и newfilename - старое и новое имя файла.
Будем считать, что файлы виртуальных дисков вами созданы и перейдем к настройке Linux SCSI target. Для этого перейдем в /etc/tgt где мы увидим файл targets.conf и директорию conf.d. Предполагается что для каждой цели мы будем использовать отдельный конфигурационный файл, которые следует снабдить расширением .conf и размещать в указанной директории.
Следует помнить, что так как iSCSI-диск является аналогом обычного диска, то с одной целью может работать только один инициатор, исключение - кластерные системы, где одна цель может быть сразу подключена к нескольким узлам.
Создадим новый файл конфигурации:
Затем откроем созданный файл и внесем в него следующее содержимое:
В начале секции после директивы target указывается IQN - полностью определенное имя цели, которое имеет следующий формат:
- year-mo - год и месяц регистрации домена
- reversed_domain_name - доменное имя, записанное в обратном порядке
- unique_name - уникальное имя цели
Внутри секции цели мы указали следующие опции:
- backing-store - указывает путь к блочному устройству или файлу
- initiator-address - IP-адрес инициатора, , если он не указан, то доступ сможет получить любое устройство.
- incominguser - имя пользователя и пароль, необязательная опция, используется для дополнительной безопасности, по требованию стандарта длина пароля должна быть равна 12 символам.
Если вы хотите предоставлять в одной цели два и более блочных устройства, то для каждого из них добавьте отдельной строкой опцию backing-store, это же касается и initiator-address, их тоже можно указать несколько.
Сохраним файл конфигурации и перезапустим службу Linux SCSI target:
Проверить работу портала можно командой:
Которая покажет все подключенные к нему цели и предоставляемые ими блочные устройства.
На этом настройку цели можно считать законченной. Как видим, никаких особых сложностей в создании iSCSI хранилища в Linux-системах нет.
В статье приводится порядок настройки сервера, предоставляющего блочные данные по протоколу iSCSI (программная СХД).
Требования
Установка
Установить необходимые пакеты
sudo apt install targetcli-fb
Настройка targetcli
Войти в консоль управлени я
Отобразить текущую конфигурацию командой ls:
/> ls
o- / . [. ]
o- backstores . [. ]
| o- block . [Storage Objects: 0]
| o- fileio . [Storage Objects: 0]
| o- pscsi . [Storage Objects: 0]
| o- ramdisk . [Storage Objects: 0]
o- iscsi . [Targets: 0]
o- lo. [Targets: 0]
o- vhost . [Targets: 0]
Создать блочное устройство в backstores , выполнить /backstores/block create storage01 /dev/<disk_name>:
/backstores/block create storage01 /dev/ <disk_name>
Created block storage object storage01 using /dev/ <disk_name> .
где <diskname> - имя диска
Аналогичным образом добавить необходимое количество дисков.
Проверить результат командой ls:
/> ls
o- / . [. ]
o- backstores . [. ]
| o- block . [Storage Objects: 1]
| | o- storage01 . [/dev/vdb (20.0GiB) write-thru deactivated]
| o- fileio . [Storage Objects: 0]
| o- pscsi . [Storage Objects: 0]
| o- ramdisk . [Storage Objects: 0]
o- iscsi . [Targets: 0]
o- loopback . [Targets: 0]
o- vhost . [Targets: 0]
Создать target командой /iscsi create:
Проверить результат командой ls:
Поскольку выполняется настройка программного iscsi-target для стендирования, с целью упрощения процесса настройки отключить контроль доступа:
set attribute generate_node_acls=1
set attribute demo_mode_write_protect=0
Создадать LUN на основе объекта хранилища в backstores
/iscsi/iqn.20. ea6d5709/tpg1> luns/ create /backstores/block/storage01
Created LUN 0.
Аналогичным образом добавить необходимое количество LUN.
После выполнения инструкций данного раздела вернитесь на предыдущую статью
Читайте также: