Ramdisk for windows server 2012 r2

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 диск.

A RAM disk is a virtual disk created in a free area of the memory (RAM) that it sees by the OS as a separate physical disk. Due to the RAM disk being stored in the fast RAM, all read/write operations on this disk are performed almost instantaneously, even faster than when using an SSD (the data transfer speed of the most productive SSDs is about 560 MB/s, while DDR4 memory – 12,000-25,000 MB/s.)

It is recommended to use a RAM disk in systems with an excess of free memory. You can use the RAM disk to place the cache or temporary files of apps/system, temporary SQL databases. Thus you can achieve a significant increase in the applications and databases performance.

In Windows OS, there are no integrated tools to create RAM disks, so you have to use third-party software to do it (AMD RAMDisk, ImDisk, PassMark OSFMount, StarWind RAM Disk, etc.).

However, you can create a RAM disk in Windows Server without using any third-party apps. To do it, you can use the iSCSI driver.

First, install the iSCSI Target Server component (it is the part of the File and Storage Services role).

If you have Windows Firewall enabled, you must allow iSCSI Service traffic.

To allow traffic to the loopback interface for iSCSI, change the value of the DWORD parameter AllowLoopBack to 1 in the HKLMSoftwareMicrosoftiSCSI Target registry key. You can change the registry parameter from PowerShell using a single command:

Set-ItemProperty -Path 'HKLM:SOFTWAREMicrosoftiSCSI Target' -Name AllowLoopBack -Value 1

Now open the PowerShell console and create a 5 GB virtual RAM disk using this command:

New-IscsiVirtualDisk -Path "ramdisk:testRAM.vhdx" -Size 5GB

Now you need to create an iSCSI target pointing to the IP address of your server (not localhost!):

New-IscsiServerTarget -TargetName targetRAMDisk -InitiatorIds @("IPAddress:10.1.1.200")

Connect the RAM disk to the created iSCSI target:

Add-IscsiVirtualDiskTargetMapping -TargetName targetRAMDisk -DevicePath "ramdisk:testRAM.vhdx"

Run the iSCSI Initiator management console through Server Manager.

Specify the IP address of your server in the Targets tab and click Quick Connect to add your iSCSI target.

You can connect the iSCSI Target with the command:

Get-IscsiTarget | Connect-IscsiTarget

Open the Disk Management console and make sure that the new 5 GB disk appeared there. This is the RAM disk we created. Initialize the disk, create a partition and format it. Assign a disk letter to it.

Now you can move app files to the RAM disk and reconfigure your software to use it.

After rebooting the server, the RAM disk is removed with all its contents and you will have to re-create it again.

Some third-party programs that create RAM disks allow saving RAM disk data as a file on your hard drive. When the system is restarted, the data are extracted and moved to the RAM disk.

To remove your RAM disk, use the following commands:

Remove-IscsiVirtualDiskTargetMapping -TargetName targetRAMDisk -DevicePath "ramdisk:testRAM.vhdx"
Remove-IscsiServerTarget -TargetName targetRAMDisk
Remove-IscsiVirtualDisk -Path "ramdisk:testRAM.vhdx"

Изучая разные методы повышения производительности работы СУБД 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-диска:

# mkdir /mnt/ramdisk1
# mkdir /mnt/ramdisk1-backup

Форматируем отдельный SSD диск для сохранения/восстановления данных RAM-диска при выключении/включении хостовой ОС Linux:

# mkfs -t ext4 /dev/cciss/c0d1

Проверяем монтирование созданного на SSD диске раздела в каталог для хранения резервной копии:

# mount /dev/cciss/c0d1 /mnt/ramdisk1-backup

Обратите внимание на то, что свободное место в каталоге /mnt/ramdisk1-backup всегда должно быть не меньше, чем размер планируемого содержимого RAM-диска. В противном случае мы можем столкнуться с ситуацией, при которой окажется невозможно сохранить данные RAM-диска при выключении сервера, что приведёт к потере всех данных на этом RAM-диске.

Выясним идентификатор UUID SSD-диска:

# blkid /dev/cciss/c0d1

В конец системного конфигурационного файла /etc/fstab добавляем директивы монтирования RAM-диска и диска для хранения в соответствующие каталоги:

# nano /etc/fstab

...
# Mount RAM-disk
#
tmpfs /mnt/ramdisk1 tmpfs defaults,size=30725M 0 0
#
# Mount SSD-disk for RAM saving/restoring
#
UUID=619be6d2-9023-4a46-8c0e-26206fe683f4 /mnt/ramdisk1-backup ext4 defaults 0 0

При описании директивы создания RAM-диска нам желательно сразу правильно спланировать его размер, учитывая то, что размер диска должен быть немного больше, чем объём планируемого блочного устройства. Это нужно для того, чтобы в дальнейшем избежать сигнализации систем мониторинга о том, что исходный RAM-диск переполнен. Например, в нашем случае в fstab при запуске системы создаётся RAM-диск размером 30725MB, а на этом диске мы в последующем будем создавать файл размером 30720MB, который и будет в дальнейшем транслироваться в виде блочного устройства из LIO в SAN.

Настраиваем службу lio-config-controller

Создадим скрипт, который будет представлять собой основу для работы специальной службы systemd, которую мы назовём, например, lio-config-controller.service. Эта служба будет управлять запуском и остановкой блочного устройства, транслируемого в SAN через конфигурацию LIO.

# nano /usr/local/sbin/lio-config-controller.sh

Наполним скрипт содержимым:

#!/bin/sh
#

LogFile="/var/log/script_lio-config-controller.log"

AddToLog()
{
  echo $(date +"%F %T") $1
  echo $(date +"%F %T") $1 >> $LogFile
}

RunStartMode()
{

  AddToLog " ------- Script START mode session started ------- "
  AddToLog "Restore RAM-disk data from file..."
  if [ -e /mnt/ramdisk1-backup/ramdisk1.img ]
  then
    AddToLog "Saved image was found. Copying an image from disk to memory started..."
    cp /mnt/ramdisk1-backup/ramdisk1.img /mnt/ramdisk1
    AddToLog "Copy complete."

  else
    AddToLog "Saved image was not found. Create a new image file..."
    fallocate --length=30720M /mnt/ramdisk1/ramdisk1.img
    AddToLog "Creation completed."
  fi

  AddToLog "Flush LIO config..."
  targetcli clearconfig confirm=True

  AddToLog "Create LIO backstores..."
  targetcli /backstores/fileio create file_or_dev=/mnt/ramdisk1/ramdisk1.img name=FS04-RAMDisk1 write_back=false

  AddToLog "Create LIO Targets..."
  targetcli /qla2xxx create naa.50014380029a1644
  targetcli /qla2xxx create naa.50014380029a1646

  AddToLog "Create LIO backstores mappings to Targets..."
  targetcli /qla2xxx/naa.50014380029a1644/luns create /backstores/fileio/FS04-RAMDisk1
  targetcli /qla2xxx/naa.50014380029a1646/luns create /backstores/fileio/FS04-RAMDisk1

  AddToLog "Create ACLs..."
  AddToLog " - ACL for Initiator KOM-WS-NODE1..."
  targetcli /qla2xxx/naa.50014380029a1644/acls create c003ff9bfee40008
  targetcli /qla2xxx/naa.50014380029a1644/acls create C003FF9BFEE40009
  targetcli /qla2xxx/naa.50014380029a1646/acls create c003ff9bfee4000a
  targetcli /qla2xxx/naa.50014380029a1646/acls create C003FF9BFEE4000B
  AddToLog " - ACL for Initiator KOM-WS-NODE2..."
  targetcli /qla2xxx/naa.50014380029a1644/acls create c003ff2369260000
  targetcli /qla2xxx/naa.50014380029a1644/acls create C003FF2369260001
  targetcli /qla2xxx/naa.50014380029a1646/acls create c003ff2369260002
  targetcli /qla2xxx/naa.50014380029a1646/acls create C003FF2369260003

  AddToLog "Save LIO config..."
  targetcli saveconfig
  AddToLog "Copy of LIO configuration saved to /etc/rtslib-fb-target/saveconfig.json"
  AddToLog "Script finished."
}

RunStopMode()
{
  AddToLog " ------- Script STOP mode session started ------- "
  AddToLog "Flush LIO config..."
  /usr/bin/targetctl clear
  AddToLog "Save RAM-disk data to persistent file..."
  if [ -e /mnt/ramdisk1/ramdisk1.img ]
  then
    AddToLog "Image file in RAM-disk was found. Copying an image from memory to disk started..."
    cp /mnt/ramdisk1/ramdisk1.img /mnt/ramdisk1-backup
    AddToLog "Copy complete."
  else
    AddToLog "WARNINIG! Image file in RAM-disk was not found."
  fi
  AddToLog "Script finished."
}

case "$1" in
  start)
    RunStartMode
    ;;
  stop)
    RunStopMode
    ;;
  *)
    echo "Usage: $0 {start|stop}" >&2
    exit 1
    ;;
esac

Как видно, скрипт может работать в двух основных режимах:

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-файл.

Сделаем скрипт исполняемым:

# chmod +x /usr/local/sbin/lio-config-controller.sh

Так как наш скрипт предполагает наличие в системе уже смонтированных дисков, перед его вызовом мы должны удостовериться в том, что эти диски действительно смонтированы. Оформим вызов скрипта, как службы systemd, таким образом, чтобы у службы (юнита) lio-config-controller.service была зависимость от юнитов, отвечающих за монтирование соответствующих дисков.

Выясним то, какие имена имеют автоматически генерируемые юниты монтирования интересующих нас дисков:

# systemctl list-units --type=mount

Как видим, в нашем случае юниты имеют имена «mnt-ramdisk1.mount» и «mnt-ramdisk1x2dbackup.mount«.

Создадим новый юнит lio-config-controller.service, который будет выполнять наш скрипт, загружая и останавливая тем самым конфигурацию LIO. При этом не забудем выставить зависимость от юнитов монтирования нужных нам дисков.

# nano /etc/systemd/system/lio-config-controller.service

Наполним конфигурацию юнита следующим образам:

[Unit]
Description=LIO Target Subsystem configuration controller service
After=mnt-ramdisk1.mount mnt-ramdisk1x2dbackup.mount
Requires=mnt-ramdisk1.mount mnt-ramdisk1x2dbackup.mount

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/lio-config-controller.sh start
ExecStop=/usr/local/sbin/lio-config-controller.sh stop
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

Так как в процессе остановки службы может потребоваться некоторое время на операцию сброса содержимого RAM-диска на SSD, дополнительно добавим таймаут ожидания остановки службы. Разумеется, если вместо SSD для хранения используется более медленный HDD, имеет смысл увеличить этот таймаут. В нашем случае этот таймаут составляет 300 секунд или 5 минут. При использовании SSD-диска величину таймаута можно сделать и ниже. Для расчёта оптимальной величины можно использовать фактическое время, затрачиваемое на сохранение содержимого RAM-диска, которое фиксируется скриптом в логе /var/log/script_lio-config-controller.log.

Включаем автоматическую загрузку созданного нами юнита в конфигурации systemd:

# systemctl enable lio-config-controller.service

В опорном скрипте созданной нами службы lio-config-controller используется утилита targetcli, которая позволяет нам управлять конфигурацией LIO. Из официальных репозиториев Debian Linux установим пакет targetcli-fb, позволяющий работать с LIO в Debian и содержащий соответствующую утилиту:

# apt-get install targetcli-fb

Так как загрузкой и выгрузкой конфигурации LIO у нас будет заниматься собственная служба, нам потребуется остановить и отключить автоматический запуск стандартной службы rtslib-fb-targetctl, устанавливаемой в систему из пакета targetcli-fb. Вся ранее настроенная конфигурация LIO при этом будет очищена.

# systemctl stop rtslib-fb-targetctl
# systemctl disable rtslib-fb-targetctl

После всех проделанных изменений можно перезагрузить конфигурацию служб systemd:

# systemctl daemon-reload

Теперь можно выполнить проверку того, как в автоматическом режиме отрабатывает созданная нами конфигурация при выключении и включении хостовой ОС Linux.

Базовая проверка и отладка

Перезагружаем сервер и после завершения загрузки ОС проверяем то, что созданная нами служба lio-config-controller успешно запущена:

# systemctl status lio-config-controller

Дополнительно можно проверить то, в какой последовательности отработал запуск служб systemd в процессе запуска ОС Linux. Для этого нам потребуется включить и настроить службу journald, как это описано в статье «Включение режима сохранения логов служб systemd через journald в Linux». После соответствующей настройки системы можно посмотреть логи интересующих нас служб, связанных с монтированием дисков, на предмет времени их запуска и остановки:

# journalctl --boot=-1 --unit=mnt-ramdisk1.mount
# journalctl --boot=-1 --unit=mnt-ramdisk1x2dbackup.mount
# journalctl --boot=-1 --unit=lio-config-controller.service

Основные этапы работы скрипта, вызываемого службой lio-config-controller можем посмотреть в логе, который указан в самом начале скрипта:

# cat /var/log/script_lio-config-controller.log

Проверяем то, что LIO загружен именно в той конфигурации, что мы описали в скрипте

# targetcli ls

Как видно из нашего примера, ранее обозначенная в скрипте конфигурация 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-диска при выключении/включении ОС:

# journalctl --unit=lio-config-controller.service 
# cat /var/log/script_lio-config-controller.log

Все операции должны отрабатывать последовательно и без ошибок. И здесь лучше не жалеть времени на скрупулёзную проверку корректной и своевременной отработки каждого этапа. Только так можно рассчитывать на то, что данные с 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-диска, как таковой. Здесь каждый для себя выводы делает сам исходя из своего практического опыта и степени «избалованности»

Как создать RAM диск в оперативной памяти средствами Windows Server

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 диск.

Источник

Создание RAM диска на Windows Server 2012 R2 средствами WinRamTech Ramdisk Enterprise

Создадим RAM диск на Windows Server 2012 R2. Выделим из оперативки 32 Гб в отдельный диск R. Используем для этого софт WinRamTech Ramdisk Enterprise.

Для создания RAM диска нам понадобится оперативка. Вставляем в сервер память или выделяем её виртуальной машине:

Итак, 32 Гб оперативки добавили.

Качаем WinRamTech Ramdisk Enterprise, лучше русскую версию. Я использую официальную с сайта:

Запускаем Диспетчер устройств (Device Manager):

Выделяем компьютер, в меню Action > Add legacy hardware. Запускается мастер добавления нового железа:

Next. Выбираем Install the hardware that I manually select from a list (Advanced):

Next. Выбираем Show All Devices:

Next. Нажимаем кнопку Have Disk.

В обзоре заходим в папку с ПО WinRamTech Ramdisk Enterprise, подпапка ENG, выбираем файл RAMDriv.inf:

Open. Обнаружили модель WinRamTech RAMDisk Enterprise (x64):

Next. Начинается установка:

Установлено. Кликаем Finish:

В диспетчере устройств видим новое устройство WinRamTech RAMDisk Enterprise (x64):

Заходим в свойства и переходим во вкладку Ram Disk Properties. Здесь всё самое вкусное:

Выбираем диск R, указываем размер 32768 MB (Это 32 гигабайта), выбираем файловую систему NTFS, присваиваем название диску RAM, ID ставим 0. Про дополнительные настройки не буду писать, мне они не нужны в настоящее время. Вы можете сконфигурировать образ диска, сжатие и т.п. Нажимаем OK:

Источник

Создание RAM диска на Windows Server 2012 R2 средствами Windows через драйвер iSCSI

Создадим RAM диск на Windows Server 2012 R2. Выделим из оперативки 32 Гб в отдельный диск R. Используем для этого средства Windows через драйвер iSCSI.

Для создания RAM диска нам понадобится оперативка. Вставляем в сервер память или выделяем её виртуальной машине:

Итак, 32 Гб оперативки добавили.

Добавляем серверу роль iSCSI Target Server:

Настраиваем Windows Firewall. Выполняем:

Запускается оснастка Windows Firewall. Нажимаем Allow an app or feature through Windows Firewall:

Выбираем iSCSI Service и ставим галки на Domain, Private, Public:

В настройках реестра убеждаемся в наличие значения:

HKLMSoftwareMicrosoftiSCSI Target
Value Name: AllowLoopBack
Type: REG_DWORD
Value: 1

Запускаем Powershell и создаём виртуальный диск как Ramdisk:

Создаём target iSCSI:

Я сначала пробовал на 127.0.0.1, но что-то не срослось. Пришлось использовать локальный IP адрес, на нём всё завелось.

Мапим Ramdisk на target iSCSI:

Запускаем консоль Server Manager и кликаем Tools > iSCSI Initiator:

Просят запустить iSCSI сервис, соглашаемся:

Запускается настройка iSCSI Initiator Properties:

Указываем в Target адрес, у меня в коде выше был 10.10.30.10, кликаем Quick Connect.

Login Succeeded. Всё в порядке. В оснастке Disk Management можно увидеть новый диск:

Настроил его как R.

Тестируем с помощью ATTO Disk Benchmark.

И видим засаду — скорось чтения/записи очень мала, по сравнению с RAM диском от WinRamTech Ramdisk Enterprise:

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

Источник

Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target

Изучая разные методы повышения производительности работы СУБД 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-диска, как таковой. Здесь каждый для себя выводы делает сам исходя из своего практического опыта и степени «избалованности»

Источник

I’m testing & playing different Windows Server 2012 & Hyper-V networking scenarios with 10Gbps, Multichannel, RDAM, Converged networking etc. Partially this is to find out what works best for us in regards to speed, reliability, complexity, supportability and cost.

Basically you have for basic resources in IT around which the eternal struggle for the prefect balance finds place. These are:

• CPU
• Memory
• Networking
• Storage

We need both the correct balance in capabilities, capacities and speed for these in well designed system. For many years now, but especially the last 2 years it very save to say that, while the sky is the limit, it’s become ever easier and cheaper to get what we need when it comes to CPU, Memory. These have become very powerful, fast and affordable relative to the entire cost of a solution.

Networking in the 10Gbps era is also showing it’s potential in quantity (bandwidth), speed (latency) and cost (well it’s getting there) without reducing the CPU or memory to trash thanks to a bunch of modern off load technologies. And basically in this case it’s these qualities we want to put to the test.

The most trouble some resource has been storage and it has been for quite a while. While SSD do wonders for many applications the balance between speed, capacity & cost isn’t that sweet as for our other resources.

In some environments were I’m active they have a need for both capacity and IOPS and as such they are in luck as next to caching a lot of spindles still equate to more IOPS. For testing the boundaries of one resource one needs to make sure non of the others hit theirs. That’s not easy as for performance testing can’t always have a truck load of spindles on a modern high speed SAN available.

RAMDisk to ease the IOPS bottleneck

To see how well the 10Gbps cards with and without Teaming, Multichannel, RDMA are behaving and what these configuration are capable of I wanted to take as much of the disk IOPS bottle neck out of the equation as possible. Apart from buying a Violin system capable of doing +1 million IOPS, which isn’t going to happen for some lab work, you can perhaps get the best possible IOPS by combining some local SSD and RAMDisk. RAMDisk is spare memory used as a virtual disk. It’s very fast and cost effective per IOPS. But capacity wise it’s not the worlds best, let alone most cost effective solution.

I’m using free RAMDisk software provided by StarWind. I chose this as they allow for large sized RAMDisks. I’m using the ones of 54GB right now to speed test copying fixed sized VHDX files. It install flawlessly on Windows Server 2012 and it hasn’t caused me any issues. Throw in some SSDs on the servers for where you need persistence and you’re in business for some very nice lab work.

You also need to be aware it doesn’t persist data when you reboot the system or lose power. This is not an issue if all we are doing is speed testing as we don’t care. Otherwise you’ll need to find a workaround and realize those ‘”flush the data to persistent storage” isn’t full proof or super fast, the SSDs do help here.

You have to register but the good news is that they don’t spam you to death at all, which I find cool. As said the tool is free, works with Windows Server 2012 and allows for larger RAMDisks where other free ones are often way to limited in size.

It has allowed me to do some really nice testing. Perhaps you want to check this out as well. WARNING: The below picture is a lab setup … I’m not a magician and it’s not the kind of IOPS I have all over the datacenters with 4 Cheapo SATA disks I touched my special magic pixie dust.

Some quick tests with a 52GB NTFS RAMDisk formatted with a 64K NTFS Allocation unit size.

I also tested with another free tool from SoftPerfect ® RAM Disk FREE. It performs well but I don’t get to see the RAMDisk in the Windows Disk Management GUI, at least not on Windows Server 2012. I have not tested with W2K8R2.

Как создать RAM диск в оперативной памяти средствами Windows Server

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 диск.

Источник

Создание RAM диска на Windows Server 2012 R2 средствами Windows через драйвер iSCSI

Создадим RAM диск на Windows Server 2012 R2. Выделим из оперативки 32 Гб в отдельный диск R. Используем для этого средства Windows через драйвер iSCSI.

Для создания RAM диска нам понадобится оперативка. Вставляем в сервер память или выделяем её виртуальной машине:

Итак, 32 Гб оперативки добавили.

Добавляем серверу роль iSCSI Target Server:

Настраиваем Windows Firewall. Выполняем:

Запускается оснастка Windows Firewall. Нажимаем Allow an app or feature through Windows Firewall:

Выбираем iSCSI Service и ставим галки на Domain, Private, Public:

В настройках реестра убеждаемся в наличие значения:

HKLMSoftwareMicrosoftiSCSI Target
Value Name: AllowLoopBack
Type: REG_DWORD
Value: 1

Запускаем Powershell и создаём виртуальный диск как Ramdisk:

Создаём target iSCSI:

Я сначала пробовал на 127.0.0.1, но что-то не срослось. Пришлось использовать локальный IP адрес, на нём всё завелось.

Мапим Ramdisk на target iSCSI:

Запускаем консоль Server Manager и кликаем Tools > iSCSI Initiator:

Просят запустить iSCSI сервис, соглашаемся:

Запускается настройка iSCSI Initiator Properties:

Указываем в Target адрес, у меня в коде выше был 10.10.30.10, кликаем Quick Connect.

Login Succeeded. Всё в порядке. В оснастке Disk Management можно увидеть новый диск:

Настроил его как R.

Тестируем с помощью ATTO Disk Benchmark.

И видим засаду — скорось чтения/записи очень мала, по сравнению с RAM диском от WinRamTech Ramdisk Enterprise:

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

Источник

Создание RAM диска на Windows Server 2012 R2 средствами WinRamTech Ramdisk Enterprise

Создадим RAM диск на Windows Server 2012 R2. Выделим из оперативки 32 Гб в отдельный диск R. Используем для этого софт WinRamTech Ramdisk Enterprise.

Для создания RAM диска нам понадобится оперативка. Вставляем в сервер память или выделяем её виртуальной машине:

Итак, 32 Гб оперативки добавили.

Качаем WinRamTech Ramdisk Enterprise, лучше русскую версию. Я использую официальную с сайта:

Запускаем Диспетчер устройств (Device Manager):

Выделяем компьютер, в меню Action > Add legacy hardware. Запускается мастер добавления нового железа:

Next. Выбираем Install the hardware that I manually select from a list (Advanced):

Next. Выбираем Show All Devices:

Next. Нажимаем кнопку Have Disk.

В обзоре заходим в папку с ПО WinRamTech Ramdisk Enterprise, подпапка ENG, выбираем файл RAMDriv.inf:

Open. Обнаружили модель WinRamTech RAMDisk Enterprise (x64):

Next. Начинается установка:

Установлено. Кликаем Finish:

В диспетчере устройств видим новое устройство WinRamTech RAMDisk Enterprise (x64):

Заходим в свойства и переходим во вкладку Ram Disk Properties. Здесь всё самое вкусное:

Выбираем диск R, указываем размер 32768 MB (Это 32 гигабайта), выбираем файловую систему NTFS, присваиваем название диску RAM, ID ставим 0. Про дополнительные настройки не буду писать, мне они не нужны в настоящее время. Вы можете сконфигурировать образ диска, сжатие и т.п. Нажимаем OK:

Источник