about NetApp

Как вы уже заметили, в 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.

Что-то мы с вами все про технику и про технику. Отвлечемся на сегодня. Несколько лет назад, еще в 2009 году, один из сооснователей компании NetApp – Дейв Хитц, о котором я тут несколько раз уже упоминал, написал книгу под несколько шокирующим названием “HOW TO CASTRATE A BULL: Unexpected Lessons on Risk, Growth, and Success in Business” – “Как кастрировать быка: Неожиданные уроки риска, роста и успеха в бизнесе”. Книга, как вы понимаете, рассказывает историю основания и развития компании NetApp, ну и на примере разнообразных набитых в процессе шишек рассматриваются какие-то “уроки жизни” в этом бизнесе. Название взялось вот откуда: Хитц после колледжа подрабатывал на ранчо с ковбоями (в Америке они существуют и по сей день), и вспоминает, что многие из простых жизненных уроков и историй оттуда хорошо подошли и к миру IT-бизнеса.

Эта книжка (на английском) у меня есть целиком, но я бы не хотел заниматься откровенным пиратством, поэтому не буду выкладывать ее в открытый доступ (и вас бы просил этого не делать), но если кто хочет почитать – пришлите мне весточку в комменты или на romx@mail.ru, я пришлю вам текст. Книжка на английском, но, в принципе, читается неплохо.

В книге есть несколько действительно поучительных историй, одна из них – про то, как они увольняли сооснователя компании, друга в человеческих взаимоотношениях, да вдобавок и принесшего им первые инвестиционные деньги, и вообще фактического лидера компании в первые ее годы, с поста главы компании, CEO. ??стория, увы, с которй очень часто сталкиваются многие стартапы, когда выясняется, что методы работы или взгляды на будущее у бывших друзей расходятся. В какой-то момент становится ясно, что без хирургического вмешательства не обойтись, как бы болезненно для всех присутствующих оно ни было.

Вот эту главу для вас на днях я и решил перевести.

Continue reading ‘Оффтопик: Глава из How to Castrate a Bull’ »

Я вам тут решил регулярно докладывать о тех переводах Best Practices, что я делаю для компании Netwell и их библиотеки техдокументации в помощь клиентам, разворачивающим и использующим системы хранения NetApp (со временем, быть может, мы и для других вендоров такое сможем, пока просто на большее рук не хватает).
Однако, к сожалению, у NetApp их пишет целая команда, а перевожу их - я один. Поэтому приходится из всего потока, который ежемесячно добавляется в библиотеку самого NetApp, выбирать самое ценное и нужное. Это не значит, что остальное бесполезное. Напротив, там бывают весьма интересные тексты и руководства. Вот я и подумал, что было бы неплохо делать такой дайджест по новым документам на английском языке, котрые пока не переводились, но, возможно, читающие по-английски вполне смогут для себя полезное из них почерпнуть.

В этом месяце я бы хотел обратить ваше внимание на следующие публикации:
Using Red Hat Client with NetApp Storage over NFS
This report helps you to get the best from your Linux® NFS clients when used in an environment that includes NetApp® storage.

Best Practice Guide for Microsoft SQL Server and SnapManager 7.0 for SQL Server with Data ONTAP Operating in 7-Mode
This document describes the best practices and offers insight into design considerations when deploying Microsoft SQL Server on NetApp storage systems running Data ONTAP® operating in 7-Mode, with the goal of achieving effective and efficient storage deployment planning and end-to-end data protection and retention planning. The scope of this guide is limited to technical design guidelines based on the design principles and preferred standards that NetApp recommends for storage infrastructure when deploying aforementioned versions of Microsoft SQL Server. The end-to-end implementation is out of scope of this report.

NetApp SnapManager 2.0 for Hyper-V on Clustered Data ONTAP 8.2
This technical report provides guidelines and best practices for integrated architecture and implementations of Microsoft Hyper-V with NetApp storage solutions. The NetApp technologies discussed in this technical report are important to achieving an integrated storage solution that is cost effective, operationally efficient, flexible, and environmentally friendly.

Microsoft Exchange 2013 and SnapManager for Exchange Best Practices Guide for Clustered Data ONTAP
Microsoft Exchange 2013 and SnapManager for Exchange Best Practices Guide for 7-Mode Data ONTAP
Many organizations have come to rely on Microsoft® Exchange Server to facilitate critical business e-mail communication processes, group scheduling, and calendaring on a 24/7 basis. System failures might result in unacceptable operational and financial losses. Due to the increasing importance of Microsoft Exchange Server, data protection, disaster recovery, and high availability are of increasing concern. Companies require quick recovery with little or no data loss. With Microsoft Exchange Server databases growing rapidly, it is increasingly difficult to complete time-consuming backup operations quickly.

Best Practice Guide for Microsoft SQL Server and SnapManager 7.0 for SQL Server with Clustered Data ONTAP
Today’s business applications are more data centric than in the past, requiring fast and reliable access to intelligent information structures that are often provided by a high-performance relational database system. Many organizations use Microsoft SQL Server as a back-end datastore for mission-critical business applications. The latest release, Microsoft SQL Server 2012, delivers performance, scalability, availability, and security. This best practice guide is intended for storage administrators and database administrators to help them successfully deploy Microsoft® SQL Server® 2012, 2008, and 2005 on NetApp® storage.
(примечание romx: Этот документ, скорее всего, будет переведен до Нового года)

Virtualizing Oracle RAC on Red Hat Enterprise Virtualization 3.1 and NetApp Clustered Data ONTAP
This solution guide provides guidelines and best practices for architecting, deploying, and managing Oracle RAC on NetApp clustered Data ONTAP® storage systems. Example scenarios, validation procedures, and implementation guidelines are described in detail. Best practices for implementation and operation are provided as needed.

SnapDrive 7.0 for Windows SMB 3.0: Best Practices and Deployment Guide
NetApp® SnapDrive® for Windows® (SDW) helps you to perform storage-provisioning tasks and manage data in Microsoft® Windows environments. You can run SnapDrive software on Windows® hosts in either a physical or a virtual environment. SnapDrive software integrates with Windows Volume Manager so that storage systems can serve as virtual storage devices for application data in Windows Server® 2008 R2 and Windows Server 2012. It can also be used to provision storage for Windows virtual machines hosted on ESX® hypervisors.

SnapDrive 7.0 for Windows for Clustered Data ONTAP 8.2 - Best Practices Guide for SAN Environments
SnapDrive 7.0 for Windows for Data ONTAP 8.2 Operating in 7-Mode: Best Practices Guide
This technical report provides best practices guidelines when implementing SnapDrive for Windows in clustered Data ONTAP 8.2 in SAN environments. For best practice guidelines in SMB, refer to TR-4218: SnapDrive 7.0 for Windows SMB 3.0 Best Practices and Deployment Guide.

??так, в прошлом посте я мельком упомянул, что кроме volume reallocation у NetApp есть еще aggregate reallocation (ключ команды запуска reallocate –A). ?? вот с ним начинается некоторое непонимание. Дело в том, что, как я показывал на примере в постах ранее, одной из необходимых операций при расширении aggregate является проведение reallocation блоков тома, для более равномерного распределения их по дискам aggregate. При этом, хотя операция проводится над aggregate, но используется НЕ aggregate reallocate, а совсем вовсе даже volume reallocation!

?? вот это принципиальный момент, вызывающий путаницу. Почему оптимизируя aggregate, мы делаем это через volume reallocate, почему не aggregate reallocate, и что же тогда делает этот aggregate reallocation?

Data ONTAP выражается тут однозначно:

NOTE: -A is for aggregate (freespace) reallocation. Do NOT use -A after growing an aggregate if you wish to optimize the layout of existing data; instead use reallocate start -f /vol/ for each volume in the aggregate.

Для начала давайте посмотрим чуть более сложную структуру aggregate, которую я рисовал в прошлый раз.

На aggregate у нас расположены, как правило, не один, а множество volume.

Volume reallocate выполняется для отдельного тома, НО НЕ для всех томов aggregate разом. Вы, в случае рассматриваемой процедуры изменения размеров aggregate и увеличения нижележащих в нем дисков, должны последовательно провести reallocation для всех томов на aggregate.

Как вы видите на рисунке выше, если мы сделали reallocate для тома А, и не делали для тома В, то мы получим что-то, похожее на рисунок выше. Один том – перераспределился на добавленные диски, а второй – нет. К тому же у нас неравномерно распределилость оставшееся свободное место, как вы помните, непрерывность кусков свободного пространства для хорошей работы механизма выделения экстентов очень важно. а представьте теперь, что на aggregate не два тома, а несколько десятков или даже сотен, как это бывает? ?? при этом reallocate кому-то сделали, а кому-то – нет?

Дальше, как вы видите, том В начал заплняться неравномерно по дискам, как мы уже рассмотрели выше в предыдущем посте, с потенциальным образованием “дисковых хотспотов”

Что же сделает aggregate reallocation (reallocate –A), если, к примеру, на части его томов будет проведен volume reallocation, а на части нет? Он, как и написано выше, оптимизирует свободное пространство на aggregate, при этом оставив часть томов в неоптимизированном состоянии.

Как вы видите на рисунке выше, свободное место на aggregate действительно “оптимизировалось”, с точки зрения aggregate, да. Поэтому в случае использования reallocate после расширения aggregate новыми томами, и более равномерного “растасовывания” блоков томов по новому пространству aggregate, сперва выполните volume reallocate для КАЖДОГО тома на aggregate, а вот потом уже начинайте, если это необходимо, использовать aggregate reallocate.

Таким образом, вы видите, что volume reallocate и aggregate reallocate это ДВА РАЗНЫХ вида реаллокации блоков. В первом случае реаллоцируются блоки, принадлежащие тому, указанному в качестве аргумента команды, а во втором, при запуске ее с ключом –А, реаллоцируется своеобразный “том, состоящий из свободных блоков” на aggregate, и упорядочивается свободное пространство, сжимаются “дыры” в нем, и пространство, незанятое данными, становится “более непрерывным”, но при этом сами тома, с блоками данных, в ходе этой операции не оптимизируются, и если они были неоптимально размещены по дискам, то так неоптимальными и останутся, несмотря на завершившийся процесс aggregate reallocation.

Часть третья рассказа про реаллокацию задерживается, но будет на этой неделе.
А пока я бы хотел рассказать, что Translation Project в моем лице перевел и выложил еще несколько интересных и важных документов.
Это обновление TR-3702 про виртуализацию Microsoft Hyper-V. Документ старый, который начат был еще для Hyper-V 1.0, и с тех пор несколько раз дописывался. Я сильно надеялся, что в связи с выходом 2012 R2 его все же сподобятся капитально переписать, повыкидывав оттуда старье, типа Windows 2008 еще-не-R2, но авторы просто в очередной раз дописали к нему в хвост главу про Server 2012 и SnapManager. Ну и то хлеб. Занимающиеся серверной виртуализацией Microsoft - посмотрите, там бывает полезное.

Очень интересный, на мой взгляд, документ про работу с Thin Provisioning в Data ONTAP - TR-3965. Тема использования и правильной настройки thin provisioning, увы, все еще крайне слабо освоена админами, все еще у многих есть и предубеждения, и непонимание. ?? предубеждение от непонимания - в первую очередь. Документ несложен, с картинками, и приводит типовые рекомендации настроек для ряда систем, например для SQL Server, Exchange, vSphere и Oracle DB, так что - рекомендую.

Еще одна очень интересная и все еще, отчего-то, не вполне ясная для многих тема - TR-3441 Windows Multipathing и Data ONTAP: Fibre Channel и iSCSI
Если вы посмотрите на номер TR, вы увидите, что тема документа очень старая, и исходный текст был написан давно. Тем не менее, я и мои коллеги, по-прежнему видим, что у многих пользователей с темой настройки и использования multipathing есть проблемы. А так как как раз недавно этот документ был в очередной раз обновлен и переписан под текущее состояние, то мы с Netwell решили, что такой документ в библиотеке тоже нужен. Если вам интересна тема многопутевого (multipath) подключения по блочным протоколам, как по FC, так и по Ethernet/iSCSI, тема MPIO, DSM, политик балансировки, ALUA и их использования, то вот этот документ делался для вас.

Наконец, это полностью переписанный с нуля TR-3633 Best Practices for Oracle Database and NetApp.
Старый, который я тоже переводил, был большой, бестолковый, запутанный и устаревший чуть более чем полностью (чего стоили лишь упоминания ядер Linux ветки 2.4, RHEL 4, Solaris 8, и детальная настройка гигабитного адаптера, который не выпускается и не продается уже лет шесть.).
Новый - это краткий (всего около 20 страниц), сжатый, выкинувший все окаменевшие говна текст, который, хоть и крайне беглый по сути, но все же очень любопытный текст “по делу”.
А еще его писал не индус ;). Нет, я совсем не расист, но попереводите техдокументацию с мое - будете ценить неиндийских авторов таких документов. :)
На момент публикации этого поста TR-3633 еще не был выложен в паблик, но будет доступен в течение недели (я отправил его на “аппрув” вчера).

По-прежнему с благодарностью принимаются предложения и рекомендации по тематике следующих переводов. Пока мы планируем в следующем году больше внимания уделить Clustered Data ONTAP, раз уж она теперь главное направление удара компании.

Отдельно, в завершение, я хочу отметить, что все приведенные на страничке техбиблиотеки Netwell переведенные документы - это “хобби-проект”, это не официальные переводы NetApp, и компания не несет за их содержание никакой ответственности, не поддерживает их (но и не мешает, спасибо им за это) и не авторизует данные переводы (не обращайтесь и не жалуйтесь в NetApp по поводу них). Это в чистом виде community project меня, romx, и компании Netwell, дистрибутора NetApp, которая решила такую библиотеку переводов в помощь админам вести. Спасибо нам :)