Окружения vSAN и VMware vCloud Foundation (VCF) на базе vSAN предлагают экстраординарную гибкость в масштабировании. Емкость можно увеличивать вертикально, добавляя устройства в хосты, или горизонтально, за счет добавления новых узлов. Вместе с представленной поддержкой емкости устройств до 32 Тб в vSAN 7, необходимо разобраться – как же экстремально большие флэш-устройства влияют на проектирование? Рассмотрим вопрос проектирования более детально.
Больший объем хранилища эквивалентен большему объему потенциального ввода/вывода.
В общем виде хранение большого объема данных не отличается от хранения маленького объема. Но в окружениях с общим хранилищем (Shared Storage), отличие заключается в том, что больше данных, в форме виртуальных машин, может приводить к большему числу потенциальных чтений и записей.
Как в архитектуре гиперконвергентной инфраструктуры (HCI), так и в трехуровневой архитектуре, увеличение объема может приводить к возникновению узких мест в самых неожиданных местах. Например, трехуровневые архитектуры, как правило, генерируют больше нагрузки на контроллеры хранилища при увеличении объема сырого хранилища. Архитектура гиперконвергентной инфраструктуры (HCI) может увеличивать нагрузку на сеть при операциях записи с большего числа виртуальных машин на физических хостах.
Может показаться, что устройства высокой плотности могут обеспечить хорошую цену на один терабайт хранилища, но при этом они могут не справится с обеспечением рабочих нагрузок обращений к данным. Технический объем будет доступен, но при этом производительность обращения к данным будет не приемлемой. Для vSAN и VCF есть несколько путей приспособиться к этому.
Рекомендации для шины устройства и протокола.
Многие устройства высокой плотности привязаны к числовому значению объема и не предполагают уровней производительности и целостности, как правило ожидаемых в корпоративных окружениях. Флэш-устройства хранения с интерфейсом SATA относятся к данной категории. Такие устройства будут постоянно перегружены в борьбе за производительность и целостность из-за различных ограничений протокола, таких как: полудуплексная сигнализация, одно-командные очереди и более ресурсоемкая обработка ввода/вывода процессором. Устройства с SATA-подключением лучше подходят для конечных устройств и домашнего сегмента, так как характеристики SATA не рассчитаны на одновременный двунаправленный доступ к общему хранилищу.
При рассмотрении возможности использования устройств большого объема, следует отталкиваться от флэш-устройств на базе SAS. Следует отметить, что NVMe – это превосходный стандарт и это лишь вопрос времени, когда этот высокоэффективный протокол шины захватит корпоративные окружения. Устройства NVMe с использованием NAND флэш ИЛИ 3D XPoint уже доминируют в областях с фокусом на производительности, таких как кэширование и буферизация.
Устройства высокой плотности могут создавать излишнюю нагрузку на общих адаптерах шины хоста (HBA), SAS в данном случае подходит лучше, чем SATA, но узкие места все равно могут возникать на общем контроллере, по мере увеличения траффика. Устройства NVMe не подвержены подобным проблемам, так как каждое устройство NVMe содержит собственный контроллер.
Рекомендация: Для устройств с большим объемом необходимо использовать как минимум устройства на базе SAS, идеальным же выбором на данный момент являются устройства NVMe.
Рекомендации по проектированию дисковых групп (Disk Group).
Использование устройств со значительно большим объемом, неизбежно будет приводить к большему объему рабочих нагрузок, что в свою очередь может создавать дополнительный стресс на уровне буферизации. Это происходит из-за того, что дополнительные виртуальные машины обычно увеличивают агрегированный размер рабочего набора между хостами в кластере. Больший объем рабочих нагрузок, как правило, обозначает больше горячих данных. Несмотря на то, что vSAN Design and Sizing Guide описывает подбор размера уровня буфера в окружении с использованием только флэш-накопителей (All-flash) на базе информации о производительности, использование буфера большого объема для обеспечения большего объема рабочих нагрузок является разумным шагом.
Добавление большего числа дисковых групп на каждый хост, предоставляет больше доступной емкости буферизации, для поддержки дополнительных рабочих нагрузок. Не менее важно то, что больше дисковых групп увеличивают число возможных параллельных операций ввода/вывода.
Рассчитывая необходимую производительность, зачастую слишком много внимания уделяют уровню хранения (Capacity Tier), особенно при увеличении емкости на хостах. Уровень буферизации (Buffer Tier) обеспечивает максимальное увеличение скорости ввода/вывода, а уровень хранения (Capacity Tier) обеспечивает максимальную скорость постоянного хранилища. Когда уровень хранения (Capacity Tier) не обладает достаточной высокой производительностью, длительная запись на высоком уровне может сокрушить возможности буфера. Скорость очистки буфера, обычно (но не всегда) зависит от производительности уровня хранения. В таком случае использование более быстрых флэш-устройств и/или их большего количества может увеличить производительность уровня хранения. Это поможет сократить задержку на уровне буфера за счет более быстрой очистки (передачи) и позволит избежать задержки на уровне гостевых виртуальных машин.
Отключение дедубликации (Deduplication) и сжатия (Compression) также являются возможными опциями увеличения производительности уровня хранения. Дедубликация и сжатие – это процессы, которые требуют дополнительной нагрузки во время опустошения буфера, напрямую сокращающие скорость опустошения. Устройства большего размера, предоставленные кластеру, могут обеспечить требуемый объем, без необходимости включения данных возможностей.
Рекомендации по времени эвакуации и восстановления.
Больший потенциальные объем обозначает более длительное время эвакуации, при условии использования исходной производительности сети.
Одной и той же сети с пропускной способностью 10 Gbps для хостов, которые теперь обладают новым объемом, в 4, 8 или 12 раз больше предыдущих конфигураций, может попросту не хватить для обеспечения такой плотности виртуальных машин на хостах. Подробнее об этом я писал в статье «Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть». Корректно сбалансированный кластер vSAN будет всегда иметь доступные хосты для любых потенциальных повторных синхронизаций объектов данных, которые помогают поддерживать их на заданном уровне соответствия. Процесс автоматизирован и прозрачен для администратора. Но скорость, с которой он происходит, зависит от производительности сети и устройств хранения. Предполагаемое время эвакуации хоста и восстановления приближается к уровню комфорта, когда необходимое время для переноса всей емкости с одного хоста на другой в случае выхода хоста из строя не выходит за рамки возможного простоя.
Рекомендации по количеству хостов.
Устройства высокой плотности провокационны, так как могут обеспечить необходимый объем при помощи меньшего числа устройств и/или хостов. Минимальное число хостов, необходимое для обеспечения определенного уровня устойчивости осталось прежним. Кроме того, несмотря на то, что каждый хост добавляет свою емкость, также он добавляет нагрузку на процессор и память, необходимую для обработки ввода/вывода. Значительное увеличение части ресурсов кластера может привести к возникновению узких мест.
Итоги.
Устройства хранения высокой плотности открывают новые возможности для узлов vSAN. Гибкость архитектуры позволяет быстрее адаптировать практически любое решение vSAN. Также при проектировании следует учесть, чтобы кластер смог справится со всей возможной нагрузкой при обработке увеличенной емкости. Необходимо уделить отдельное внимание при проектировании решения с устройствами хранения высокой плотности, чтобы принять верные решения при покупке и получить ожидаемую производительность.
Комментариев нет:
Отправить комментарий