Аналог tmpfs в windows
Обновлено: 04.07.2024
Tmpfs — временное файловое хранилище во многих Unix-like ОС. Предназначена для монтирования файловой системы, но размещается в ОЗУ вместо физического диска. Подобная конструкция является RAM диском.
Содержание
Семантика
Все данные в Tmpfs являются временными, в том смысле, что ни одного файла не будет создано на жёстком диске. После перезагрузки все данные, содержащиеся в Tmpfs, будут утеряны.
Память, используемая для Tmpfs, варьируется в размерах в зависимости от количества размещённых файлов в ней и может быть расширена за счёт swap. Многие Unix дистрибутивы используют Tmpfs по умолчанию для размещения /tmp или для разделения памяти. Это можно увидеть в выводе команды df, например:
Реализации
SunOS/Solaris
SunOS 4 включала ранние разработки Tmpfs; она впервые появилась в SunOS 4.0 в конце 1987, вместе с новым ортогональным управлением адресным пространством, что позволяет разместить любой объект в памяти. [1] [2]
В Solaris /tmp размещалась в Tmpfs, что стало стандартом в Solaris 2.1, вышедшей в Ноябре 1994. Вывод команды df в Solaris показывал swap как файловую систему любого Tmpfs раздела:
Linux
Tmpfs стал поддерживаться Linux с версии 2.4 и больше. [3] Tmpfs (так же известная как shmfs) отличается от Linux RAM диска динамическим выделением памяти и перемещением неиспользуемых страниц в swap. RAMfs, наоборот, не использует swap (это может быть как преимуществом, так и недостатком). Вдобавок, MFS и некоторые старые версии RAMfs, не изменяли свой размер динамически, а оставались того размера, как были примонтированы.
Использование Tmpfs, например:
которая будет возрастать до 1 GiB с 10240 инодами в ОЗУ/swap и доступная только владельцу директории /space. Максимальный размер файловой системы может быть изменён "на лету", например:
В Tmpfs могут быть размещены любые директории, хранящие временные данные, удаляемые при перезагрузке системы: /var/lock, /var/run, /tmp и др. Кроме того, для уменьшения количества дисковых операций (в целях максимального повышения производительности системы или экономии ресурса твердотельных накопителей) в Tmpfs иногда размещают директории, которые обычно хранят данные между перезагрузками, например, /var/tmp (эта директория нередко очищается, хотя рекомендовано этого не делать [4] ) или директории кэширования некоторых программ (интернет-браузеров).
Tmpfs была реализована в NetBSD версии 4.0, 10 сентября 2005 [5] . В FreeBSD 7.0 появилась портированная из NetBSD Tmpfs. [6] В DragonFly BSD, с версии 2.5.1, тоже имеется портированная из NetBSD реализация Tmpfs.
Microsoft Windows
В Windows имеется приблизительный аналог Tmpfs в виде "временных файлов". Файлы, созданные с атрибутом FILE_ATTRIBUTE_TEMPORARY и флагом FILE_FLAG_DELETE_ON_CLOSE размещаются в ОЗУ и записываются на жёсткий диск только если системе не хватает оперативной памяти. Таким образом, "временные файлы" аналогичны Tmpfs, за исключением того, что при нехватке памяти они записываются по указанному при их создании пути, а не в файл подкачки. Этот метод часто используется на серверах с TransmitFile для подготовки контента и его буферизацией перед отправкой клиенту.
Примечания
- ↑Peter Snydertmpfs: A Virtual Memory File System (PDF). Архивировано из первоисточника 1 мая 2012.Проверено 2 июля 2010.
- ↑Hal L. SternSunOS 4.1 Performance Tuning (GZipped PostScript). Архивировано из первоисточника 1 мая 2012.Проверено 2 июля 2010.
- ↑Daniel RobbinsAdvanced filesystem implementor's guide (September 1, 2001). Архивировано из первоисточника 1 мая 2012.Проверено 2 июля 2010. Статья, описывающая реализации в Linux
- ↑Filesystem Hierarchy Standard
- ↑Julio M. Merino VidalNetBSD-SoC: Efficient memory file-system (February 24, 2006). Архивировано из первоисточника 1 мая 2012.Проверено 2 июля 2010.
- ↑Derek MorrFreeBSD tmpfs manpage (December 2, 2008). Архивировано из первоисточника 1 мая 2012.Проверено 2 июля 2010.
Ссылки
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое "Tmpfs" в других словарях:
TmpFS — (Temporary File System) est le nom générique données à tout système de fichiers Unix temporaire. Tout fichier créé dans un tel système de fichier disparait lors de l arrêt du système. L implémentation par défaut du tmpfs des noyaux Linux 2.6.x[1] … Wikipédia en Français
Tmpfs — (Temporary File System) est le nom générique données à tout système de fichiers Unix temporaire. Tout fichier créé dans un tel système de fichier disparait lors de l arrêt du système. L implémentation par défaut du tmpfs des noyaux Linux 2.6.x[1] … Wikipédia en Français
TMPFS — ist ein Dateisystem, das in vielen Unix artigen Betriebssystemen als Ramdisk eingesetzt wird. Hierbei wird der Arbeitsspeicher statt der Festplatte als Speicher benutzt. Funktion Alles, was in tmpfs gespeichert wird, ist nur temporär, da es nicht … Deutsch Wikipedia
Программное обеспечение RAM-дисковода позволяет рассматривать часть RAM (памяти) компьютера, как если бы это был диск, с именем тома и, если это поддерживается операционной системой, буквой диска . RAM-диск имеет гораздо более быстрый доступ для чтения и записи, чем жесткий диск с вращающимися пластинами, и является нестабильным , уничтожаясь вместе со своим содержимым, когда компьютер выключается или выходит из строя - нестабильность является преимуществом, если безопасность требует, чтобы конфиденциальные данные не хранились постоянно. , а также для предотвращения накопления устаревших временных данных, но это невыгодно, когда диск используется для более быстрой обработки необходимых данных. Данные можно копировать между обычным запоминающим устройством и RAM-диском, чтобы сохранить их при отключении питания и загрузить при запуске.
СОДЕРЖАНИЕ
Обзор
Функции
Возможности, которые варьируются от одного пакета к другому:
- Некоторые RAM-диски автоматически создают резервную копию содержимого на обычном запоминающем устройстве при выключении питания и загружают его при запуске компьютера. Если эта функция не предусмотрена, содержимое всегда можно сохранить с помощью сценариев запуска и закрытия или вручную, если оператор не забывает сделать это.
- Некоторое программное обеспечение позволяет создавать несколько дисков RAM; другие программы поддерживают только один.
- Некоторые диски RAM при использовании с 32-битными операционными системами (особенно 32-битной Microsoft Windows ) на компьютерах с архитектурой IBM PC позволяют использовать память выше 4 ГБ на карте памяти , если таковая имеется; эта память неуправляема и обычно недоступна. Программное обеспечение, использующее неуправляемую память, может вызвать проблемы со стабильностью.
- Некоторые диски RAM могут использовать любую «неуправляемую» или «невидимую» RAM ниже 4 ГБ на карте памяти (известной как барьер 3 ГБ ), то есть RAM в « отверстии PCI ». Примечание. Не предполагайте, что диски RAM, поддерживающие память AWE (или расширения адресации ) более 4 ГБ, также будут поддерживать неуправляемую память PAE (или расширение физического адреса ) менее 4 ГБ - в большинстве случаев этого не происходит.
FreeBSD
md - диск памяти
Этот драйвер обеспечивает поддержку четырех типов виртуальных дисков с поддержкой памяти: malloc, preload, vnode, swap. Диски могут быть созданы с помощью следующих инструментов командной строки: mdconfig и mdmfs. Ниже приводится пример использования этих программ.
Чтобы создать и смонтировать диск памяти с помощью mdmfs:
Чтобы создать и смонтировать диск памяти с помощью mdconfig:
Чтобы уничтожить ранее созданный диск:
Linux
Современные системы Linux поставляются с предустановленным доступным для пользователя виртуальным диском, установленным по адресу /dev/shm .
RapidDisk
RapidDisk - это бесплатный проект с открытым исходным кодом, содержащий модуль ядра Linux и утилиту администрирования, которая по своим функциям аналогична Ramdiskadm в Solaris (операционной системе) . С помощью утилиты rxadm пользователь может динамически подключать, удалять и изменять размер томов RAM-диска и обращаться с ними как с любым другим блочным устройством.
RAMDisk
Бесплатная утилита с открытым исходным кодом, позволяющая использовать оперативную память как папку.
tmpfs и ramfs
Пример того, как использовать tmpfs и ramfs в среде Linux, выглядит следующим образом:
После определения точки монтирования можно использовать команду mount для монтирования файловой системы tmpfs и ramfs поверх этой точки монтирования:
Теперь каждый раз при доступе к / var / ramdisk все операции чтения и записи будут происходить непосредственно из памяти.
Есть 2 различия между tmpfs и ramfs.
1) смонтированное пространство ramfs теоретически бесконечно, поскольку ramfs при необходимости будут расти, что может легко вызвать блокировку системы или сбой из-за использования всей доступной памяти или начать интенсивную подкачку, чтобы освободить больше памяти для ramfs. По этой причине может быть рекомендовано ограничение размера области рамф.
2) tmpfs поддерживается пространством подкачки компьютера
Существует также множество «оболочек» для RAM-дисков для Linux, таких как Profile-sync-daemon (psd) и многие другие, позволяющие пользователям использовать RAM-диск для ускорения работы настольных приложений, перемещая интенсивный ввод-вывод для кешей в RAM.
Майкрософт Виндоус
Непатентованный
ImDisk
ImDisk Virtual Disk Driver - это эмулятор образа диска, созданный Олофом Лагерквистом. Это бесплатно и с открытым исходным кодом , и доступен в 32- и 64-разрядные варианты. Он имеет цифровую подпись, что делает его совместимым с 64-разрядными версиями Microsoft Windows без необходимости запуска в тестовом режиме. 64-разрядная версия не имеет практических ограничений на размер RAM-диска, который может быть создан.
ImDisk Toolkit является третьей стороной, бесплатно и программное обеспечение с открытым исходным кодом , который встраивает ImDisk Virtual Disk Driver и добавляет несколько функций.
Проприетарный
AMD Radeon RAMDisk
AMD Radeon RAMDisk доступен в бесплатных версиях (RAM-диск до 4 ГБ или 6 ГБ с памятью AMD) и коммерческих версиях для дисков до 64 ГБ. Бесплатная версия поддерживает рекламу. Создает только один диск (не поддерживает несколько дисков RAM). Может периодически создаваться резервная копия на жесткий диск и автоматически загружаться при запуске компьютера. AMD Radeon RAMDisk - это измененная версия Dataram RAMDisk.
Dataram RAMDisk
RAMDisk от Dataram - это бесплатное программное обеспечение (размер диска до 1 ГБ (уменьшено с 4 до 1 ГБ - за посещение сайта в октябре 2015 г.)). Первоначально он был разработан и продан Джоном Ладжои через его частную консалтинговую компанию до 2001 г., когда он продал свои права на Сенатек , прежде чем был приобретен Датарамом. RAM-диски размером более 4 ГБ требуют регистрации и однопользовательской лицензии за 18,99 долларов США. При покупке физической оперативной памяти у Dataram лицензия RAMDisk предоставляется бесплатно. (Согласно данным государственных продаж DATARAM от 25.04.2014, это уже не так.) Совместимость со всеми 32-разрядными и 64-разрядными версиями Windows 10, Windows 8, Windows 7, Windows Vista, Windows XP, Windows Server 2008 и Windows Server 2003.
Dimmdrive RAMDisk
Gavotte RamDisk
Можно использовать расширение физического адреса для создания виртуального диска в памяти, обычно недоступной для 32-разрядных версий Microsoft Windows (как память выше точки 4 ГБ, так и память в отверстии PCI). Существует также плагин с открытым исходным кодом, который заменяет RAM-диск в PE Builder Bart на диск, основанный на rramdisk.sys Гавота.
Gilisoft RAMDisk
Программное обеспечение RAMDisk для Windows 2000/2003 / XP / Vista / Windows 7 (x32 и x64) / Windows 10 с простой настройкой, позволяет монтировать и отключать образы RAMDisk в / из файлов образа диска, а также автоматически и удобно запускать / функции выключения, 25 долларов.
Gizmo Central
Gizmo Central - это бесплатная программа, которая может создавать и монтировать файлы виртуальных дисков. Он также имеет возможность создавать RAM-диск размером до 4 ГБ, поскольку Gizmo - это 32-разрядная программа.
Passmark OSFMount
OSFMount Passmark поддерживает создание RAM-дисков, а также позволяет монтировать файлы образа локального диска (побитовые копии раздела диска) в Windows с буквой диска. OSFMount - это бесплатная утилита, разработанная для использования с PassMark OSForensics.
Примо Рамдиск
Программное обеспечение Romex Обеспечивает модный интерфейс, который работает со всеми средами Windows от (XP до Windows 10) и всеми выпусками серверов Windows с (с 2003 по 2019 в настоящее время), поддерживает до 128 дисков объемом до 32 ГБ для версии Pro и 1 ТБ для версий Ultimate и Server , поддерживает использование невидимой памяти в 32-битных версиях Windows, с сохранением при выключении или переходе в спящий режим. Доступны платные и пробные версии.
QSOFT (WinRamTech) Ramdisk Enterprise
RAM-диск, совместимый со всеми версиями Windows Workstation и Server OS (32- и 64-битными), начиная с Windows 2000. Содержимое RAM-диска можно сделать «постоянным», то есть регулярно сохранять в файл образа на жестком диске. и / или при выключении и восстановлении из того же файла образа во время загрузки. Благодаря встроенным процедурам форматирования диска и встроенной загрузке файла образа этот виртуальный диск уже полностью доступен на этапе загрузки, когда запускаются службы и автоматически запускаемые программы. Некоторые параллельные тесты двух RAM-дисков одновременно показывают, что этот RAM-диск - почти самая быстрая версия. Хотя разработка этого RAM-диска была завершена в 2017 году, RAM-диск версии 5.3.2.15 все еще можно приобрести.
SoftPerfect RAM Disk
Доступно для Windows 7, 8 и 10; и Windows Server с 2008 R2 по 2019. Может иметь доступ к памяти, доступной для Windows, то есть в 32-битных системах RAM-диск ограничен теми же 4 ГБ, что и сама 32-битная Windows. Чтобы использовать физическую память сверх 4 ГБ, вы должны установить SoftPerfect RAM Disk в 64-разрядной системе. Можно создать несколько RAM-дисков, и их можно сделать постоянными, сохраняя содержимое и восстанавливая из файла образа диска.
Эмулятор виртуального ОЗУ StarWind Software
StarWind Software создает бесплатное программное обеспечение для RAM-дисков для установки памяти как реальных дисков в Windows. Существуют версии как x86, так и x64.
Ультра RamDisk
Программное обеспечение RAMDisk, которое также может монтировать различные форматы образов компакт-дисков, такие как iso, ooo, cue, ccd, nrg, mds, img. Приложение имеет две версии, платную и бесплатную, где последняя позволяет создать один оперативный диск размером до 2 ГБ.
VSuite Ramdisk
Бесплатная версия (ограниченная 32-разрядной версией Windows Win2000 / XP / 2003) может использовать «невидимую» ОЗУ в «промежутке» от 3,25 до 4 ГБ (если на вашей материнской плате установлен чипсет i946 или выше), а также способна «экономить» на жесткий диск при отключении питания »(теоретически это позволяет использовать RAM-диск для файла подкачки Windows XP и выжить в« гибернации »). В то время как бесплатная версия позволяет установить несколько RAM-дисков, общий объем всех дисков ограничен 4096 МБ. Текущая версия VSuite Ramdisk II была переименована в Primo Ramdisk, все версии которой являются платными.
Исходный код Microsoft
Пример драйвера Ramdisk.sys для Windows 2000
Microsoft Windows предлагает «демонстрационный» RAM-диск для Windows 2000 как часть Windows Driver Kit . Ограничено использованием той же физической ОЗУ, что и операционная система. Он доступен для бесплатной загрузки с исходным кодом.
Пример RAMDisk для Windows 7/8
Microsoft предоставляет исходный код для драйвера RAM-диска для Windows 7 и 8.
Родные
Windows также имеет грубый аналог tmpfs в виде «временных файлов». Файлы, созданные с использованием как FILE_ATTRIBUTE_TEMPORARY, так и FILE_FLAG_DELETE_ON_CLOSE, хранятся в памяти и записываются на диск только в том случае, если система испытывает большую нагрузку на память. Таким образом, они ведут себя как tmpfs, за исключением того, что файлы записываются по указанному пути в ситуациях нехватки памяти, а не для места подкачки. Этот метод часто используется серверами вместе с TransmitFile для рендеринга содержимого в буфер перед отправкой клиенту.
Солярис
Рамдискадм
Ramdiskadm - это утилита в операционной системе Solaris, предназначенная для динамического добавления и уничтожения томов виртуальных дисков любого размера, определенного пользователем. Пример того, как использовать ramdiskadm для добавления нового RAM-диска в среде Solaris, выглядит следующим образом:
Ко всем созданным RAM-дискам можно получить доступ из /dev/ramdisk пути к каталогу и обращаться с ними как с любым другим блочным устройством; то есть доступ к нему осуществляется как к физическому блочному устройству, помеченному файловой системой и смонтированному, даже для использования в пуле ZFS .
Изучая разные методы повышения производительности работы СУБД SQL Server, добрался до такой интересной темы, как использование RAM-диска для размещения файлов нагруженной системной базы данных tempdb. Выяснил для себя то, что из работоспособных свободно-распространяемых инструментов для организации RAM-диска под ОС Windows Server на текущий момент многие выделяют утилиту imDisk Toolkit. Однако этот инструмент, как и прочие его аналоги, не получится использовать в кластерных конфигурациях SQL Server, где использование ресурсов оперативной памяти (далее ОЗУ) в любой момент времени может быть переключено с одного кластерного узла на другой. То есть, если и использовать в кластере RAM-диск, то он должен быть одинаково доступен всем узлам кластера, как и любой другой кластерный диск, участвующий в конфигурации кластеризованного экземпляра SQL Server.
Напрашивающимся в таком случае решением может стать использование в качестве RAM-диска ОЗУ не самих узлов кластера, а ОЗУ стороннего хоста, подключенного к узлам кластера в качестве дискового устройства через транспорт Fiber Channel SAN (как отличающийся приемлемыми показателями задержки). То есть на выделенном хосте используются локальные ресурсы ОЗУ для создания RAM-диска, после чего RAM-диск транслируется на узлы кластера через FC SAN, как блочное устройство, и может использоваться в качестве кластерного диска.
Далее я опишу пример создания такого RAM-диска на выделенном хосте с ОС Debian GNU/Linux 9 и его трансляцию в SAN с помощью Linux-IO (LIO). На сервере для обеспечения работы FC Target предварительно установлен контроллер FC HBA QLogic и задействован специальный режим работы драйвера – Target Mode.
Обязательным условием в нашем примере является то, что на Linux-хосте нужно организовать механизм сохранения данных RAM-диска при выключении ОС и восстановлении данных на RAM-диск при включении ОС с использованием выделенного SSD-диска.
Настраиваем RAM-диск на Linux
Перейдём на наш Linux-сервер, имеющий большой объем оперативной памяти, часть которой мы готовы выделить под организацию RAM-диска.
Создаём каталог для RAM-диска и каталог для хранения резервной копии содержимого RAM-диска:
Форматируем отдельный SSD диск для сохранения/восстановления данных RAM-диска при выключении/включении хостовой ОС Linux:
Проверяем монтирование созданного на SSD диске раздела в каталог для хранения резервной копии:
Обратите внимание на то, что свободное место в каталоге /mnt/ramdisk1-backup всегда должно быть не меньше, чем размер планируемого содержимого RAM-диска. В противном случае мы можем столкнуться с ситуацией, при которой окажется невозможно сохранить данные RAM-диска при выключении сервера, что приведёт к потере всех данных на этом RAM-диске.
Выясним идентификатор UUID SSD-диска:
В конец системного конфигурационного файла /etc/fstab добавляем директивы монтирования RAM-диска и диска для хранения в соответствующие каталоги:
При описании директивы создания RAM-диска нам желательно сразу правильно спланировать его размер, учитывая то, что размер диска должен быть немного больше, чем объём планируемого блочного устройства. Это нужно для того, чтобы в дальнейшем избежать сигнализации систем мониторинга о том, что исходный RAM-диск переполнен. Например, в нашем случае в fstab при запуске системы создаётся RAM-диск размером 30725MB, а на этом диске мы в последующем будем создавать файл размером 30720MB, который и будет в дальнейшем транслироваться в виде блочного устройства из LIO в SAN.
Настраиваем службу lio-config-controller
Создадим скрипт, который будет представлять собой основу для работы специальной службы systemd, которую мы назовём, например, lio-config-controller.service. Эта служба будет управлять запуском и остановкой блочного устройства, транслируемого в SAN через конфигурацию LIO.
Наполним скрипт содержимым:
Как видно, скрипт может работать в двух основных режимах:
1) Запуск c ключом start
В этом режиме скрипт будет размещать на уже доступном в системе RAM-диске в каталоге /mnt/ramdisk1 специальный файл ramdisk1.img . При этом img-файл будет вновь создаваться только в том случае, если его предыдущая копия не обнаружена на SSD-диске в каталоге /mnt/ramdisk1-backup . В случае обнаружения копии img-файла на SSD, эта копия будет восстанавливаться на RAM-диск. В дальнейшем img-файл на RAM-диске будет загружаться в конфигурацию LIO, создавая FC Target. Обратите внимание на то, что перед загрузкой новой конфигурации, текущая конфигурация LIO будет очищаться.
2) Запуск c ключом stop
В этом режиме конфигурация LIO очищается, то есть из системы удаляется FC Target, ассоциированный с img-файлом на RAM-диске. После чего происходит сохранение img-файла из RAM-диска на SSD-диск.
Оба режима работы скрипта логируют основные этапы выполняемых операций в отдельный log-файл.
Сделаем скрипт исполняемым:
Так как наш скрипт предполагает наличие в системе уже смонтированных дисков, перед его вызовом мы должны удостовериться в том, что эти диски действительно смонтированы. Оформим вызов скрипта, как службы systemd, таким образом, чтобы у службы (юнита) lio-config-controller.service была зависимость от юнитов, отвечающих за монтирование соответствующих дисков.
Выясним то, какие имена имеют автоматически генерируемые юниты монтирования интересующих нас дисков:
Как видим, в нашем случае юниты имеют имена " mnt-ramdisk1.mount " и " mnt-ramdisk1\x2dbackup.mount ".
Создадим новый юнит lio-config-controller.service, который будет выполнять наш скрипт, загружая и останавливая тем самым конфигурацию LIO. При этом не забудем выставить зависимость от юнитов монтирования нужных нам дисков.
Наполним конфигурацию юнита следующим образам:
Так как в процессе остановки службы может потребоваться некоторое время на операцию сброса содержимого RAM-диска на SSD, дополнительно добавим таймаут ожидания остановки службы. Разумеется, если вместо SSD для хранения используется более медленный HDD, имеет смысл увеличить этот таймаут. В нашем случае этот таймаут составляет 300 секунд или 5 минут. При использовании SSD-диска величину таймаута можно сделать и ниже. Для расчёта оптимальной величины можно использовать фактическое время, затрачиваемое на сохранение содержимого RAM-диска, которое фиксируется скриптом в логе /var/log/script_lio-config-controller.log .
Включаем автоматическую загрузку созданного нами юнита в конфигурации systemd:
В опорном скрипте созданной нами службы lio-config-controller используется утилита targetcli, которая позволяет нам управлять конфигурацией LIO. Из официальных репозиториев Debian Linux установим пакет targetcli-fb, позволяющий работать с LIO в Debian и содержащий соответствующую утилиту:
Так как загрузкой и выгрузкой конфигурации LIO у нас будет заниматься собственная служба, нам потребуется остановить и отключить автоматический запуск стандартной службы rtslib-fb-targetctl, устанавливаемой в систему из пакета targetcli-fb. Вся ранее настроенная конфигурация LIO при этом будет очищена.
После всех проделанных изменений можно перезагрузить конфигурацию служб systemd:
Теперь можно выполнить проверку того, как в автоматическом режиме отрабатывает созданная нами конфигурация при выключении и включении хостовой ОС Linux.
Базовая проверка и отладка
Перезагружаем сервер и после завершения загрузки ОС проверяем то, что созданная нами служба lio-config-controller успешно запущена:
Дополнительно можно проверить то, в какой последовательности отработал запуск служб systemd в процессе запуска ОС Linux. Для этого нам потребуется включить и настроить службу journald, как это описано в статье "Включение режима сохранения логов служб systemd через journald в Linux". После соответствующей настройки системы можно посмотреть логи интересующих нас служб, связанных с монтированием дисков, на предмет времени их запуска и остановки:
Основные этапы работы скрипта, вызываемого службой lio-config-controller можем посмотреть в логе, который указан в самом начале скрипта:
Проверяем то, что LIO загружен именно в той конфигурации, что мы описали в скрипте
Как видно из нашего примера, ранее обозначенная в скрипте конфигурация LIO успешно загружена и созданы цели FC Target.
После этого настраиваем зонирование на оптических коммутаторах SAN, чтобы на серверах на базе Windows Server стал доступен соответствующий FC Target.
В нашем случае презентованный LUN доступен на обоих узлах кластера Windows Server по двум путям, обеспечивая тем самым повышенную доступность и производительность. Получившееся общее для двух Windows-систем дисковое устройство форматируем в NTFS и добавляем в кластер в качестве общего кластерного диска.
Теперь настало время убедиться в том, что в случае возникновения необходимости отключения Linux-сервера, предоставляющего свою оперативную память, всё содержимое кластерного диска будет сохранено.
Проверка сохранения содержимого RAM-диска
Для проверки создаём на кластерном диске Windows Server какие-то файлы и запоминаем их содержание, то есть копируем туда какой-то осмысленный контент. После этого выводим в кластере диск в режим обслуживания или просто переводим в состояние Offline, чтобы избежать кластерных попыток активировать диск на соседнем узле кластера в тот момент, когда мы отключим для проверки Linux-сервер.
После этого перейдём на Linux-сервер и вызовем выключение его ОС штатным способом. В ходе завершения работы ОС обращаем внимание на то, что таймаут остановки службы lio-config-controller используется именно тот, который мы указали в настройках юнита systemd - lio-config-controller.service:
После проверочного отключения снова включаем Linux-сервер и дожидаемся успешного запуска ОС, инициализации RAM-диска (с восстановлением данных из копии на SSD диске) и его последующей трансляции в конфигурацию LIO. После того, как всё "взлетело", можем снова проанализировать лог работы службы lio-config-controller и лог работы самого скрипта на предмет корректности этапов выключения/включения RAM-диска при выключении/включении ОС:
Все операции должны отрабатывать последовательно и без ошибок. И здесь лучше не жалеть времени на скрупулёзную проверку корректной и своевременной отработки каждого этапа. Только так можно рассчитывать на то, что данные с RAM-диска не будут в дальнейшем потеряны.
Когда все проверки на стороне Linux-сервера закончены, вернёмся в консоль управления кластером Failover Cluster Manager и убедимся в том, что кластерный RAM-диск работоспособен и успешно переводится в состояние Online. После успешного возобновления работы кластерного диска проверим его содержимое и убедимся в том, что на диске присутствуют скопированные нами ранее на этот диск файлы.
Проверка производительности RAM-диска
Сразу сделаем оговорку о том, что любые сравнительные тесты на проверку производительности всегда зависят от множества факторов. И в каждом отдельно взятом случае и отдельном рабочем окружении эти факторы могут иметь разную степень влияния на конечный результат. Поэтому в нашем конкретном случае никто не претендует на какую-то объективность. Мы лишь поделимся одним простым наблюдением.
На два рассматриваемых в нашем примере сервера с ОС Windows Server помимо RAM-диска через FC SAN (два линка FC 4G c MPIO) презентовано ещё несколько дисковых устройств, одно из которых представляет собой массив RAID10 из 12 SSD дисков Intel SATA 3G с СХД HP MSA P2000 G3. При тестировании такого дискового устройства на любом из узлов кластера получались примерно следующие пиковые показатели:
При тестировании на этих же серверах нашего RAM-диска получались следующие пиковые показатели:
Небольшое отклонение в показателях чтения в пользу СХД MSA можно попытаться объяснить опять же разными факторами, но не будем заострять на этом внимание. Внимание здесь стоит обратить на ощутимую разницу в показателях записи. При операциях с большими блоками, начиная с 512KB, на лицо выигрыш RAM-диска и по второму графику видно, что на каком-то уровне (возможно FC HBA на Linux-сервере, возможно на SAN …) просто срабатывает ограничение, и нельзя исключать того, что есть возможность улучшить полученные показатели чтения/записи. Кстати, обратите внимание также и на ощутимую разницу по показателям чтения/записи при работе с блоками 64K (рекомендуемый Microsoft размер блока при форматировании накопителей под файлы БД SQL Server).
Таким образом, привнесённый в кластер RAM-диск, в качестве места размещения файлов нагруженной системной базы данных tempdb кластеризованного экземпляра СУБД SQL Server, представляется вполне привлекательным решением.
Замечание о последовательности выключения и выключения серверов
Следует обратить внимание на то, что в случае возникновения нештатных ситуаций в ЦОД, например, в случае отключения электропитания, порядок автоматического отключения серверов должен быть настроен таким образом, чтобы физический Linux-сервер c RAM-диском выключался только после того, как завершат свою работу узлы кластера, которые используют этот RAM-диск в качестве кластерного ресурса.
Ну и, разумеется, обратного принципа следует придерживаться в процессе включения серверов. То есть Linux-сервер с RAM-диском должен запускаться, так же как и прочие СХД, раньше, чем стартуют серверы-узлы кластера Windows, использующие этот RAM-диск.
Заключение
Стоит отметить тот факт, что организацию RAM-диска описанным здесь методом можно выполнить не только на ОС Debian GNU/Linux 9, но и на других дистрибутивах Linux. А в качестве механизма трансляции RAM-диска в FC SAN можно использовать не только Linux-IO, но и такой замечательный инструмент, как SCST, пример использования которого мы уже рассматривали ранее.
Если же говорить о том, с чего мы начали, то, разумеется, можно поспорить о плюсах и минусах использования RAM-диска для системной базы данных tempdb СУБД SQL Server, равно как и об описанной здесь организации RAM-диска, как таковой. Здесь каждый для себя выводы делает сам исходя из своего практического опыта и степени "избалованности"
Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.
Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.
Но поскольку установка Debian не является предметом этой статьи, подробно ее описывать не буду.
Такой выбор в общем продиктован тем, что оперативной памяти никогда не бывает много и держать в ней что-то огромное вроде KDE не предполагалось. После установки необходимых для работы программ на жестком диске оказалось занято полтора гигабайта. Установка производилась в один раздел, без раздела swap. Оперативной памяти на компьютере установлено 16 гигабайт.
Собственно, способ
1. В файле /usr/share/initramfs-tools/scripts/local закомментируем строку:
checkfs $ root
и строку:
mount $ -t $ $ $ $
и сразу после нее вставим такой текст:
mkdir /ramboottmp
mount $ -t $ $ $ /ramboottmp
mount -t tmpfs -o size=100% none $
cd $
tar -zxf /ramboottmp/ram.tar.gz
umount /ramboottmp
2. Выполним команду mkinitramfs -o /initrd-ram.img
и после того, как она отработает, вернем файл /usr/share/initramfs-tools/scripts/local в исходное состояние.
3. В файле /etc/fstab закомментируем строку, описывающую монтирование корневого раздела / и вставим такую строку:
none / tmpfs defaults 0 0
4. Загрузим какой-нибудь другой линукс с LiveCD, чтобы полностью отвязаться от испытуемой операционной системы,
и заархивируем весь раздел с ее файловой системой:
cd /mnt/first && busybox tar -czf /mnt/work/ram.tar.gz *
после окончания вернем файл /etc/fstab в исходное состояние.
5. В итоге у нас получился линукс, состоящий всего из трех файлов:
кернела, initrd-ram.img и ram.tar.gz. Местонахождение ram.tar.gz указываем в параметре root= ядра в меню загрузчика grub:
title Linux in RAM
kernel /vmlinuz root=/dev/sdb1
initrd /initrd-ram.img
Это вся инструкция. Необходимые комментарии:
— checkfs закомментируем потому, что нет такого fsck для проверки tmpfs, не написали его;
— busybox tar используем для создания архива вместо простого tar из-за того, что в initrd нет простого tar, распаковывать наш архив будет именно busybox, и существует такой баг, что не сможет распаковать;
— звездочка в командной строке не страшна, так как в корне, обычно, нет скрытых файлов и папок, а в директориях они архивируются.
— /mnt/first — это примонтированный раздел с испытуемой ОС, а /mnt/work/ — это раздел для помещения архива.
Как это работает?
Мы изготовили специальный initrd, который при загрузке создает корневую файловую систему типа tmpfs (в этом вся соль, так как располагается она в оперативной памяти), затем смотрит на указанный в опции root= раздел, берет там файл архива, имя которого захардкожено (ram.tar.gz), и распаковывает из него все дерево ФС на эту tmpfs.
Так ФС оказывается в памяти.
Причем tmpfs обладает выгодными отличиями от рамдисков (в том числе от используемого мной для Windows) — она не блочное устройство, а файловая система, она занимает места в памяти ровно столько, сколько занимают файлы, и динамически увеличиватся, если что-то устанавливать, записывать новые файлы, и уменьшается, если деинсталлировать софт, удалять файлы. Остальная память доступна для работы ОС, программ. А еще Linux понимает, что это УЖЕ память и ее не надо кэшировать. Замечательная вещь!
Преимущества
Да, конечно, кэширование в современных ОС частично решает проблему низкой производительности дисковых устройств, но все равно необходимо время для первого прочтения файла с диска, а также он может быть выгружен из кэша в любое время и тогда понадобится время для его повторного чтения. Размещение же всей ОС в памяти является бескомпромиссным решением, гарантирующим максимально возможную скорость чтения и записи ее файлов. Простейший тест с помощью dd демонстрирует 3 гигабайта в секунду на последовательное чтение и 2 гигабайта в секунду на последовательную запись:
dd if=/dev/zero of=/test bs=1M count=500
524288000 bytes (524 MB) copied, 0.268589 s, 2.0 GB/s
dd if=/test of=/dev/null bs=1M count=500
524288000 bytes (524 MB) copied, 0.167294 s, 3.1 GB/s
Это примерно в 30 раз быстрее, чем HDD, и в 8 раз быстрее, чем SSD.
Продвинутый тест с помощью fio демонстрирует iops 349059 при случайном чтении и complete latency 0.29 микросекунд (латентность на два-три (десятичных) ПОРЯДКА меньше, чем у SSD):
В работе
Вывод команды free в типовой рабочей ситуации:
total used free shared buffers cached
Mem: 16469572 3236968 13232604 2075372 65552 2687436
Сразу после загрузки используется около 2 гигабайт памяти, из которых 1.5 занимает файловая система. При наличии 16 гигабайт ОЗУ имеется большой простор для установки даже больших приложений, как LibreOffice или Blender. Размер файла ram.tar.gz примерно полгига, что позволяет хранить его, кернел и initrd на любой небольшой флешке или на CD. Жесткого диска может вообще не быть. Такая система неубиваема. Но главное — это, конечно, скорость работы.
В заключении тридцатисекундный скринкаст о фактической скорости запуска приложений в такой системе. Нет, это не открытие приложений из трея, это запуск программ с носителя, которым в данном случае является tmpfs:
Читайте также: