Содержание
RAM диск – это виртуальный диск, созданный в свободной области оперативной памяти, который воспринимается операционной системой как отдельный физический диск. За счет, того, что RAM диск хранится в быстрой оперативной памяти, все операции чтения/записи с такого диска выполняются почти мгновенно, даже быстрее, чем при использовании SSD накопителя (у самых производительных SSD скорость передачи данных сейчас составляет около 560МБ/с, в то время как у памяти DDR4 — 12000-25000МБ/с).
Использование RAM диска целесообразно в системах с избытком оперативной памяти. На таком RAM диске можно размещать кэш и временные файлы приложений/системы, временные базы SQL, тем самым можно добиться существенного увеличения производительности приложений.
В операционной системе Windows отсутствуют встроенные средства создания RAM-дисков, поэтому в этих целях приходится использовать сторонние программы (AMD RAMDisk, ImDisk, PassMark OSFMount, StarWind RAM Disk и т.д.).
Однако в Windows Server вы можете создать RAM диск и без использования сторонних программ. Для этого можно воспользоваться драйвером iSCSI.
В первую очередь на сервере нужно установить компонент iSCSI Target Server (входит в состав роли File and Storage Services).
Если у вас включен файервол Windows, необходимо разрешить трафик для службы iSCSI Service.
Чтобы разрешить трафик на loopback интерфейс для iSCSI, нужно в ветке реестра HKLMSoftwareMicrosoftiSCSI Target изменить значение DWORD параметра AllowLoopBack на 1. Можно изменить ключ реестра из PowerShell одной командой:
Set-ItemProperty -Path ‘HKLM:SOFTWAREMicrosoftiSCSI Target’ -Name AllowLoopBack -Value 1
Теперь откройте консоль PowerShell и создайте виртуальный RAM диск размером 5 Гб командой:
New-IscsiVirtualDisk -Path "ramdisk:testRAM.vhdx" -Size 5GB
Теперь нужно создать iSCSI таргет:
New-IscsiServerTarget -TargetName targetRAMDisk -InitiatorIds @("IPAddress:10.1.1.200")
Подключим RAM диск в созданный iSCSI таргет
Add-IscsiVirtualDiskTargetMapping -TargetName targetRAMDisk -DevicePath "ramdisk:testRAM.vhdx"
Теперь нужно запустить консоль iSCSI Initiator через Server Manager
На вкладке Targets укажите IP адрес вашего сервера, нажмите Quick Connect и подключите ваш iSCSI таргет.
Теперь откройте консоль управления дисками и проверьте, что у вас появился новый диск размером 5 Гб. Это и есть тот самый RAM диск. Инициализируйте, разметьте и отформатируйте данный диск. Назначьте ему букву диска.
Теперь вы можете перенести необходимые файлы на RAM диск и перенастроить ПО на использование данного диска.
После перезагрузки сервера RAM диск удаляется (вместе со всем содержимым) и его нужно пересоздавать заново.
В некоторых сторонних программах для создания RAM дисков есть возможность сохранения данных RAM диска в файл на жестком диске. После перезагрузки системы данные извлекаются и помещаются на RAM диск.
Изучая разные методы повышения производительности работы СУБД 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-ramdisk1x2dbackup.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. При тестировании такого дискового устройства на любом из узлов кластера получались примерно следующие пиковые показатели:
499 MB/s или 3.9 Gbit/s
Чтение
791 MB/s или 6.3 Gbit/s
При тестировании на этих же серверах нашего RAM-диска получались следующие пиковые показатели:
687 MB/s или 5.5 Gbit/s
Чтение
730 MB/s или 5.8 Gbit/s
Небольшое отклонение в показателях чтения в пользу СХД 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-диска, как таковой. Здесь каждый для себя выводы делает сам исходя из своего практического опыта и степени "избалованности"
Hi, this is Mounia Rachidi, a Support Escalation Engineer on the Windows team. Today’s blog will cover the creation of a RAM DISK.
A RAM DISK is a virtual disk entirely stored in memory and accessible from any application. As the memory is much faster than physical hard disks, storing temporary data on an in-memory disk achieves a higher performance.
Furthermore; RAM Disks can be used to test the throughput of a solution while removing the spinning disks as a bottleneck.
As user mode applications can’t access physical memory without the help of a driver, the implementation of RAMDisk in Windows relies on iSCSI driver.
To set it up, you basically need to ensure that the server is running the iSCSI Target role, create a target and map the created Ramdisk to that target.
While setting a RAMDISK can be possible on a member cluster, this configuration is not recommended or supported while the cluster service is up.
Step-By-Step Walk-Through
Great! now that you have an understanding of RAMDISK concept, let’s create one…
First, you need to add the iSCSI Target Server role:
Adjust the Firewall rules:
- Press Windows Logo+R, type firewall.cpl and press Enter to open the Windows Firewall Control Panel tool.
- Click Allow an app or feature through Windows Firewall on the left.
- Scroll down and check iSCSI Service. Check Domain, Private and Public. Click OK to save the settings.
Make sure the Iscsi Target allows the LoopBack mode:
Add the registry value if not present :
Value Name: AllowLoopBack
Create a virtual disk as a Ramdisk:
New-IscsiVirtualDisk -Path "ramdisk:testRAM.vhdx" -Size 1GB
Create a target iSCSI:
New-IscsiServerTarget -TargetName targetRAM -InitiatorIds @("IPAddress:X.X.X.")
Map the Ramdisk to the iSCSI target:
Add-IscsiVirtualDiskTargetMapping -TargetName targetRAM -DevicePath "ramdisk:testRAM.vhdx"
Next, launch the iSCSI Initiator for the Server Manager console:
Connect to the iSCSI target:
In the Target field, enter the IP address specified in step 5 and click Quick Connect to detect the targets.
Next, select the row that corresponds to the right target and click Connect. The disk will subsequently be available in the disk management console.