Storage QoS в Clustered Data ONTAP 8.2
Как вы уже заметили, в NetApp вот уже пару лет как перевели “семерку”, Data ONTAP 7-mode, куда входят как “классическая” линейка 7.х.х, так и Data ONTAP 8.x 7-mode, в состояние stable, и новые фичи в них практически не появляются, а все усилия разработчиков направлены на развитие и разработку Cluster mode, или как она сейчас стала часто называться в документации Clustered Data ONTAP. Уже само появление “личного имени” свидетельствует о том, что это – окончательный продукт, в представлении NetApp (затянувшийся) переходный период подошел к концу. Это, безусловно, очень рискованный период в жизни компании (любой компании), так как Clustered Data ONTAP пока еще не стал массовым и все еще не “мэйнстрим” в представлениях клиентов. Однако, NetApp не теряет терпения, и новыми фичами, такими как SMB 3.0, NFS 4.1 и pNFS, и прочими полезными штуками, старается перетянуть пользователей на новую, прогрессивную платформу с большим будущим.
Одной из новинок Clustered ONTAP стал полноценный Storage QoS. В принципе, псевдо-QoS в нетапповских стораджах был и раньше, он назывался FlexShare, но говоря о нем NetApp всегда старался уточнить, что это, ну, “не совсем настоящий QoS”, как, допустим, кооперативная многозадачность ранних Windows и MacOS Classic была лишь “псевдо”-многозадачностью. Конечно, это лучше чем ничего, многие стораджи, других вендоров, и такой-то не имеют. Но все же не следует забывать, что FlexShare это просто способ отдать побольше приоритета в тиках системы тому, данные с которого мы считаем важными, за счет того, что мы заберем их у того тома, данные с которого мы считаем не такими важными.
Однако подлинный QoS это не просто перераспределение приоритетов системы, это возможность задать некоторую гарантированную “полосу” в ресурсах. В особенности это стало важно после того, как появилась Clustered Data ONTAP, в которой multi-tenancy, то есть “сожительство” нескольких разнородных задач в рамках одной системы и одного контроллера такой системы стала не экзотикой, а нормальной повседневной работой. Для такой работы несомненно нужен полноценный QoS в рамках системы в целом, гибко назначаемый по потребителям, которые могут мигрировать по контроллерам кластерной системы, а не просто смещенные приоритеты обслуживания для какого-то тома, привязанные к данному контроллеру.
?? вот, в 8.2 появился полноценный планировщик ввода-вывода, который позволяет назначать политики с лимитами на отдельный SVM, Storage Virtual Machine, как теперь, если вы помните, решено, для упрощения понимания, называть Vserver в Clustered ONTAP.
Вы можете задать на отдельный “виртуальный нетапп”, живущий в кластерной системе, и ресурсов в нем, его лимиты по IOPS или же по MB/s ввода-вывода (но не одновременно, отметьте это ограничение). Следуя модели “политик” (policy), ограничение задается для такой созданной политики, которая затем назначается для SVM (Vserver) в целом, или же на его отдельный том, LUN, или файлы в нем. На кластер контроллеров вы можете задать до 3500 политик, то есть решение подойдет даже для довольно больших по масштабам систем.
“Внутри” назначенных политик действует правило равных долей для всех объектов, которым назначена эта политика, например томов или LUN-ов. Таким образом, задача с более активной рабочей нагрузкой не “съест” все ресурсы ввода-вывода у задач с меньшим траффиком, они в равной мере получат заданный в политике лимит ресурса.
QoS не разделяет операции чтения или записи, соответственно нельзя отдельно ограничить поток ввода-вывода только на чтение или только на запись.
??спользовать QoS можно, например, для ограничения производительности ввода-вывода определенных приложений, к примеру сервер резервного копирования может, при начавшемся процессе резервного копирования, очень быстро “съесть” всю доступную полосу ввода-вывода контроллера, “задавив” трафиком при этом всех своих соседей по кластеру. Можно ограничить ресурсы SVM ряда подразделений, живущих в том же кластере, например задачи R&D, чтобы случайный эксперимент на их SVM не смог повлиять на доступность продакшн-систем в том же кластере. Наконец, можно обеспечивать гарантированную полосу или величину IOPS (SLA) для особо критичных задач в облачной структуре, либо наоборот, максимально доступные им ресурсы.
Storage QoS включена в Clustered Data ONTAP 8.2, и не требует лицензии, и работает на любой системе, поддерживающей cDOT 8.2.
Не совсем понятен один момент: если у нас один агрегейт, который даёт ресурсы двум SVM-кам - там понятно, как ресурсы могут быть поделены, а если каждой SVM-ке присвоены “свои” диски - как тогда делить? ??ли можно задавать именно полосу пропускания, а не процент от общей полосы?
> ??ли можно задавать именно полосу пропускания, а не процент от общей полосы?
Да, именно так, как собственно и должно быть в “настоящем QoS”
Кстати, вы упомянули в другом посте, что на данный момент DataONTAP не поддерживает синхронную репликацию. Как я понял, это имелось ввиду SnapMirror sync - вы не в курсе, когда он будет поддерживаться?
Добавлю - Clustered DataONTAP, разумеется.
Nostromo:
В 8.3 обещали, то есть где-то в первом квартале следующего года.
В “настоящем” QoS хотелось бы видеть как раз приоритизацию по весам, а не жесткое задание IOPS и mb/s, что бесполезно практически совсем.
Александр:
Во-первых, давайте не говорить за всех.
Во-вторых, вы конечно можете считать QoS то что вы написали выше, но настоящий QoS это именно задание лимита ресурса в абсолютном выражении.
Это самый примитивный шейпер, а не “настоящий QoS”. Очевидно потому, что шейпер никакого качества сервиса никому не обеспечивает. Реализация QoS подразумевает, что можно или явно гарантировать клиенту полосу, обеспечив ему должный уровень сервиса (собственно QoS), либо обеспечить приоритизацию его трафика с той же конечной целью.
Александр:
Вы ошибаетесь. Хотя шейпер и недостаточное условие для того, чтобы построить QoS, его наличие абсолютно необходимо для него. Это раз.
Два - QoS в cDOT обеспечивают политики, использующие шейпер, и именно они позволяют обеспечить качество сервиса, гарантируя ему полосу или объем IOPS, все в точности как вы и говорите.
Приоритезация была в форме FlexShare, и она совершенно точно не обеспечивает гарантию доступности ресурса, только перераспределение приоритетов, а этого, как показывает практика, часто недостаточно.
В чем конкретно я ошибаюсь? ??ли, спрошу иначе, могу я на СХД NetApp явно гарантировать определенному клиенту, скажем, 1000IOPS, и каким образом? Что мне нужно сделать для этого?
Александр:
Можно назначить не для клиента, а для SVM, насколько я понимаю, то есть на виртуального файлера.
Но если вы хотите в самом деле получить ответ, то рекомендую такие вопросы задавать не в комментах к постам прошлогодней давности, все равно их никто не читает кроме меня, а в форуме https://communities.netapp.com/groups/netapp-ru, там много компетентных пользователей, там получить ответ быстро (и правильный) куда выше.