Создание 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:

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

HKLM\Software\Microsoft\iSCSI 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

Драйвер программы эмулирует в системе виртуальный диск (раздел), физически хранящийся в оперативной памяти.
http://ru.wikipedia.org/wiki/RAM_drive

Среди множества аналогичных продуктов хочу выделить Qsoft RAMDisk «Enterprise». Русскоязычная версия распространяется бесплатно, программа обладает достаточной функциональностью и стабильностью. Последняя из доступных . Проверена на Windows 7, 8, 10
AMD Radeon RAMDisk | Primo Ramdisk | ImDisk

Предлагаю здесь делиться опытом по использованию RAM-дисков, тонкостям настройки, примерами использования и т.д.

Сообщение отредактировал velikashkin — 29.03.18, 12:00

Насколько я понимаю этот рам диск только для временных файлов в т.ч. для файла подкачки и т.д. Сделаю я на рам файл подкачки 6 гигов и что это мне даст ощутимый прирост?Он ещё каждый раз при старте системы стирается.CUDA вроде и на этой матери работает нормально,тут скорее вопрос поддерживает ли программа куду.Адоб поддерживает.

Сообщение отредактировал Shoore — 19.03.12, 01:02

funky88, во всех приложения, активно работающих с диском, производительность увеличивается на порядок. Как с этим обстоят дела в Премьере не в курсе. Можно помониторить дисковую активность.

Кстати, проверить — дело пяти минут. В шапке программа, перезагрузка не требуется. Просто пренеси на РАМ что-либо, куда производится частая запись, а на его месте сделай символьную (?) ссылку.
cmd > mklink /j «старое_расположение_папки» «новое_расположение_папки» > enter

Только не забудь при удалении рамдиска вернуть папку на место. Дисковую активность удобно мониторить этим

Сообщение отредактировал Shoore — 25.03.12, 12:42

Я использую SuperSpeed RamDisk Plus 11.5.390.x86
Размер поставил 755 МБ. Перенёс на него:
Cache IE9
Mozilla (Portable) полностью
Skype (Portable) полностью
Второй Skype с другим профилем (Portable) полностью
uTorrent 2.2 (Portable) полностью
Журналы (Logs) Windows:
Application
Security
Setup
System
Свободны ещё 305 Мб.
Единственное неудобство — планшет долго на мой взгляд выключается, включается ненамного медленнее.
На планшете стоит 4 ГБ ОП, сборка WINDOWS 7 Ultimate x86 for MSI WindPad 110W (prepared by xalex & zhuk.m)

Сообщение отредактировал zhuk.m — 19.03.12, 21:51

Видимо, на запись драйв совсем медленный.
У меня и то и другое сопоставимо, но само время увеличилось в разы.

Добавлено 19.03.2012, 21:50:

Туда, кстати, относительно немного пишется. Гораздо больше в %user%AppData и ProgramData

Добавлено 19.03.2012, 21:54:

А сами программы нет смысла там держать полностью, у них постоянные обращения идут к Профилям. Utorret вообще любой портируется переносом файлов из C:\Users\user\AppData\Roaming\uTorrent в папку с экзешником.

Сообщение отредактировал Shoore — 19.03.12, 22:10

Это потеря всех основных преимуществ SSD. Смысл его тогда использовать? По статистике, ещё ни один SSD не вышел из строя по причине износа.
Вот интересный ресурс SSD Write Endurance 25nm Vs 34nm

Сообщение отредактировал Shoore — 20.03.12, 00:06

И не забудьте настроить сохранение образа, иначе потеряется всё, что там.
Ну или резервируйте инфу на время экспериментов.

Да, и подкачку включите. 8ГБ не тот объём, что бы можно было без неё обходится. Прецедентов масса.

Сообщение отредактировал Shoore — 22.03.12, 00:01

Сообщение отредактировал 404 not found — 20.03.12, 12:44

Зависит от задач Если не класть туда системные темпы, хватит и одного-полутора ГБ.

Пока всё нормально.

Сообщение отредактировал Shoore — 20.03.12, 00:42

еще раз извиняюсь за назойливость. но впечатление, что мануал писали таджики, а переводили китайцы.
Вот на скрине:
1. это место зарезервировано под оперативу?
2. это размер, который можно использовать под RAM диск, остальное под файловую систему
так я понимаю?
а что такое 3?
спасибо

Посмотрите мой скрин выше с Монитором ресурсов. Это какое-то оборудование (часто видеокарта) железно резервирует себе часть оперативной памяти.

в общем остановился на гиге рамдиска. перенес профиль, кеш огнелиса, темп пользователя (общий боюсь не влезет, если придется что-нибудь глобальное распаковывать, или обновы какие мелкософт гигансткие выпустит), туда же всунул uTorrent Portable. Все, будем посмотреть. Сейчас наибольшую активность проявляет MES, но боюсь я с ним ничего не сделаю.

з.ы. подкачку включил, но сделал всего 2 гига, хватит ей.

Сообщение отредактировал 404 not found — 20.03.12, 19:00

Да у него активность полгига в сутки. Не страшно. Дело не столько избавится от активности, сколько повысить быстродействие.
uTorrent вообще убрать на HDD, там ему самое место.
У меня подкачка 500МБ-4ГБ пока что не вышла за рамки 500.
Файл уберите, ссылку можно. Но не нужно. Гугл у всех есть.

Сообщение отредактировал Shoore — 20.03.12, 19:09

Odysseus,
нет, это не файл подкачки, это как бы «виртуальный» диск (сорри за сочиненный на ходу термин), скорость чтения и записи у которого в разы больше, чем с жесткого диска, и равна скорости твоей оперативы.
Смысл как раз и в браузере, скорости распаковки архивов, установки игр (ну с этим на 6-8 гигах особо не разгонишся). Чего я сделал, см. выше. Откусить 1-1.5 гига от оперативы ничего страшного ( у вас часто она бывает заполнена до 80%?)
Как-то так

Сообщение отредактировал 404 not found — 20.03.12, 19:57

Как создать 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, нужно в ветке реестра HKLM\Software\Microsoft\iSCSI Target изменить значение DWORD параметра AllowLoopBack на 1. Можно изменить ключ реестра из PowerShell одной командой:

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\iSCSI 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 с помощью 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-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. При тестировании такого дискового устройства на любом из узлов кластера получались примерно следующие пиковые показатели:

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