Медленные диски для ОС, быстрые диски для данных

На протяжении многих лет я замечаю, что люди нередко склоняются к высокопроизводительному, высоконадёжному хранилищу для раздела операционной системы, но выбирают медленное, “экономичное” хранилище для критически важных хранилищ данных. Меня поражает, как часто я наблюдаю подобное, и теперь, с появлением гипервизоров, я вижу то же самое поведение, повторяющееся и там — усугубляя ранее существовавшие проблемы.

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

Во многих случаях — будь то попытка повысить производительность, обеспечить надёжность или вынужденная техническая необходимость — я вижу, как люди разделяют свои массивы хранения, помещая гипервизоры и операционные системы в один массив, а данные в другой. Но меня поражает то, что массивы, выделенные для гипервизора или операционной системы, нередко имеют огромную ёмкость и чрезвычайно высокую производительность — зачастую с использованием шпинделей 15 000 об/мин или даже твердотельных накопителей по высокой цене. И почти всегда в конфигурации RAID 1 (в соответствии с общепринятыми стандартами 1998 года).

Необходимо понять вот что: операционные системы сами по себе практически не предъявляют требований к вводу-выводу хранилища. Есть небольшой объём операций, преимущественно для системного журналирования, но это примерно всё, что требуется. Разделы операционной системы почти полностью статичны. Необходимые компоненты загружаются в память, преимущественно при загрузке, и больше не используются. Даже в случаях, когда требуется журналирование, нередко эти журналы отправляются в централизованную систему сбора логов, а не в локальную область хранения, что сокращает или вовсе устраняет эту потребность.

С гипервизорами этот эффект ещё более выражен. Поскольку гипервизоры значительно легче и менее функциональны, чем традиционные операционные системы, они ведут себя скорее как встраиваемые системы — и во многом действительно являются ими во многих случаях. Гипервизоры загружаются в память при запуске системы, и их носитель практически никогда не требуется после загрузки, кроме как для журналирования в отдельных случаях. Поскольку гипервизоры невелики по физическому размеру, даже полное время чтения гипервизора с носителя очень мало — даже на очень медленных носителях, — поскольку их общий размер очень мал.

По этим причинам производительность хранилища практически не имеет значения для операционных систем и тем более для гипервизоров. Разница между быстрым и медленным хранилищем реально сказывается только на времени загрузки системы, где разница в одну или тридцать секунд редко была бы замечена, если бы вообще была замечена. Когда кто-либо воспринимал бы даже несколько дополнительных секунд при запуске системы? В большинстве случаев запуски являются редкими событиями, происходящими самое большее раз в неделю при автоматической плановой перезагрузке в период запланированного технического обслуживания — или очень редко, иногда лишь раз в несколько лет, для систем, которые выводятся из эксплуатации только в экстренных случаях. Даже самое медленное из мыслимых хранилищ с большим запасом быстрее, чем требуется для этой роли.

Даже медленное хранилище, как правило, значительно быстрее, чем необходимо для деятельности по системному журналированию. В тех редких случаях, когда журналирование очень интенсивно, у нас есть много способов решить эту проблему. Наиболее очевидное и распространённое решение — отправлять журналы на дисковый массив, отличный от того, который использует операционная система или гипервизор. Это очень простое решение и в конечном итоге весьма практичное в случаях, когда это оправдано. Другое распространённое и весьма полезное решение — вовсе отказаться от хранения журналов на локальном устройстве и отправлять их в утилиту удалённого сбора журналов, такую как Splunk, Loggly или ELK.

Другая основная проблема, которую большинство людей связывают с операционными системами и гипервизорами, — это надёжность. Нередко больше усилий направляется на защиту этих относительно незначительных аспектов системы, а не часто незаменимых данных. Однако операционные системы и гипервизоры при необходимости легко пересоздаются с нуля с помощью чистой установки и ручной перенастройки. Детали, которые могут быть утрачены, как правило, сравнительно несложно воссоздать.

Это не означает, конечно, что эти системные файловые системы не нужно резервировать — конечно, нужно (в большинстве случаев). Но даже в случае сбоя резервных копий потеря раздела ОС или файловой системы редко означает настоящую катастрофу — лишь неудобство. Существуют способы восстановления почти во всех случаях без доступа к исходным данным, при условии что раздел “данных” является отдельным. И в силу природы операционных систем и гипервизоров изменения в них редки, поэтому резервные копии можно делать реже — возможно, запускать вручную только при применении обновлений!

Во многих современных системах в пространствах DevOps и облачных вычислений стало очень распространённым рассматривать файловые системы операционных систем и гипервизоров как полностью одноразовые — поскольку они определяются удалённо через образ системы или систему управления конфигурацией. В таких случаях, которые становятся всё более и более распространёнными, нет никакой необходимости в защите данных или резервных копиях, поскольку вся система спроектирована для воссоздания, почти мгновенно, без какого-либо специального взаимодействия. Система полностью самовоспроизводится. Это дополнительно обесценивает необходимость защиты системной файловой системы.

В совокупности, отсутствие потребности в производительности и отсутствие потребности в защите и надёжности, обеспечиваемых прежде всего через простое воссоздание, — и мы получаем системную файловую систему с очень отличными от общепринятых потребностями. Это не означает, что мы должны быть безрассудны в отношении нашего хранилища: мы по-прежнему хотим избегать отказов хранилища во время работы системы, а излишнее пересоздание является расточительством времени и ресурсов, даже если и не оказывается катастрофическим. Поэтому соблюдение тонкого баланса важно.

Именно по этим причинам размещение операционной системы или гипервизора на том же массиве хранения, что и данные, стало сегодня распространённой практикой — поскольку практически нет необходимости в одновременном доступе к системным файлам и к файлам данных, и мы получаем отличный синергетический эффект: быстрое время загрузки для ОС и отсутствие негативного влияния на время доступа к данным после того, как система запущена. Это основной метод, которым системные проектировщики сегодня решают задачу эффективного использования хранилища.

Когда операционная система или гипервизор должны быть отделены от массивов с данными — что по-прежнему может случаться по самым разным причинам — мы, как правило, стремимся обеспечить разумную надёжность при низких затратах. При использовании традиционного хранилища (локальных дисков) это означает применение небольших, медленных, недорогих шпиндельных накопителей для хранения операционной системы, как правило в простой конфигурации RAID 1. Реальный пример — использование SATA-дисков 5400 об/мин класса “экологичных” в минимально возможных размерах. Они потребляют мало энергии и недороги в приобретении. SSD и высокоскоростные SAS-диски следует избегать, поскольку они требуют доплаты за защиту, которая нерелевантна, и производительность, которая полностью бесполезна.

В менее традиционном хранилище распространено использование бюджетного высокоплотного SAN, консолидирующего низкоприоритетное хранилище для многих систем на общих, медленных массивах без репликации. Это эффективно лишь в крупных средах, которые могут обосновать дополнительную архитектурную сложность и достичь достаточной плотности в процессе консолидации хранилища для создания необходимой экономии затрат — однако в крупных средах этого добиться относительно несложно. Загрузочные устройства SAN могут использовать очень бюджетные массивы для многих серверов с целью снижения затрат. В виртуальной среде это может означать низкопроизводительное хранилище для виртуальных дисков с ОС и отдельный высокопроизводительный пул для виртуальных дисков с данными. Это даст тот же эффект, что и стратегия загрузки с SAN, но в более современном исполнении и может легко использовать архитектуру SAN в качестве основы.

Наконец, и это наиболее радикальный вариант, существует общепринятое практическое правило для гипервизоров — устанавливать их на SD-карты или USB-накопители, а не на традиционное хранилище, поскольку их потребности в производительности и надёжности несравнимо ниже, чем у традиционных операционных систем. Как правило, если такой накопитель выйдет из строя во время работы системы, система продолжит работу без каких-либо проблем — накопитель не используется после первоначальной загрузки. Проблема обнаружится только при перезагрузке, когда можно будет воспользоваться резервным загрузочным устройством — второй SD-картой или USB-накопителем. Это официальная рекомендация VMware vSphere, нередко рекомендуется представителями Microsoft для HyperV, официально поддерживается OEM-производителями HyperV, а также зачастую рекомендуется (но не так широко поддерживается) для систем Xen, XenServer и KVM. Использование SD-карт или USB-накопителей для хранения гипервизора фактически превращает сервер виртуализации во встраиваемую систему. Хотя это может казаться неестественным системным администраторам, привыкшим считать традиционные диски необходимостью для серверов, важно помнить, что высококритичные корпоративные системы, такие как маршрутизаторы и коммутаторы, служат десятилетиями и используют именно эту стратегию по тем же самым причинам.

Распространённая стратегия для гипервизоров в этом режиме встраиваемой системы с SD-картами или USB-накопителями — иметь два таких устройства (которые могут быть одной SD-картой и одним USB-накопителем) с копией гипервизора на каждом. При отказе одного устройства загрузка со второго практически столь же эффективна, как традиционная система RAID 1. Но в отличие от большинства традиционных установок RAID 1, у нас также есть относительно простой способ тестирования обновлений системы: обновлять только одно загрузочное устройство за раз и проверять процесс перед обновлением второго — оставляя надёжный, проверенный запасной вариант на случай, если обновление версии пойдёт не так. Эта практика на самом деле была распространена на крупных Unix RISC-системах, где загрузочные устройства нередко представляли собой локальные программные RAID 1-наборы, поддерживавшие аналогичную практику, — особенно в среде AIX и Solaris.

Следует также отметить, что, хотя этот подход является лучшей практикой для большинства сценариев с гипервизорами, на самом деле нет никаких причин, по которым его нельзя было бы применить и к полным файловым системам операционных систем — за исключением того, что это нередко требует больше усилий. Некоторые ОС, особенно Linux и BSD, прекрасно умеют устанавливаться в режиме встраиваемой системы и могут быть легко адаптированы для установки на SD-карту или USB-накопитель при небольшой предварительной подготовке. Такой подход совсем не распространён, но нет никаких технических причин, по которым в правильных обстоятельствах это не было бы отличным решением — за исключением того, что практически никогда не следует устанавливать ОС непосредственно на физическое оборудование, а не поверх гипервизора. В тех случаях, когда физическая установка необходима, этот подход крайне актуален.

При проектировании и планировании систем хранения помните о реальных паттернах чтения и записи во время работы системы. И помните, что хранение данных существенно изменилось с тех пор, как были разработаны многие традиционные рекомендации, и не все знания, лежащие в их основе, применимы сегодня или применимы в равной мере. Думайте не только о том, какие подсистемы хранения будут запрашивать его производительность, но и о том, как они будут взаимодействовать друг с другом (например, две системы никогда не запрашивают хранилище одновременно или будут регулярно конфликтовать?) и насколько важна скорость их доступа. Общие функции операционной системы могут работать крайне медленно на сервере баз данных без каких-либо негативных последствий — важна лишь скорость доступа к базе данных. Даже доступ к бинарным файлам приложений нередко несущественен, поскольку они тоже, будучи загруженными в память, остаются там и на текущую производительность влияет только скорость памяти.

Всё это не означает призыва к разделению подсистем хранения ОС и данных: нередко это нецелесообразно. В прошлом я писал о том, что консолидация этих подсистем очень часто является наилучшим решением, и это по-прежнему так. Но существуют и многие разумные случаи, когда разделение определённых потребностей в хранилище имеет смысл — нередко при работе с крупномасштабными системами, где можно снизить затраты, выделив дорогостоящее хранилище для одних нужд и бюджетное для других. Именно в таких случаях я хочу показать, что операционные системы и гипервизоры следует считать наименее приоритетными как с точки зрения производительности, так и надёжности — за исключением самых крайних случаев.