about NetApp

Я тут уже, было дело, бухтел, что, видимо вследствие того, что у NetApp в компании большой вес имеют “инженеры”, довольно часто в продукт попадают какие-нибудь функциональные, но маловыразительные, или, того хуже, запутывающие термины.
Вот кто знает, почему управление (включение, выключение, и прочая настройка) дедупликацией скрывается за командой консоли asis? Что это за “асис” такой, что он значит, и как связан с дедупликацией?
А вот, оказывается, когда-то, в самом начале, еще, фактически, до релиза, функция дедупликации у NetApp называлась Advanced Single Instance Store, или ASIS (что такое был не-адвансед, а простой single instance store, не помнит уже никто, наверное). Потом аббревиатуру заменили на самоописывающий термин “deduplication”, а команда осталась.

Ранее, осенью, я писал несколько статей на тему, “Что такое Reallocation, как она работает, и как ей пользоваться правильно?”, и, соответственно, в консоли есть команда reallocate.
Но теперь, с 8.2, в Cluster-mode, появилась новая функция, называющаяся очень похоже - relocate. Путаница со всем этим нам, очевидно, еще предстоит. :-/

Relocate - “перемещение” - это новая возможность Cluster-mode, доступная с версии 8.2, которая позволяет не прерывая работы системы, “на ходу”, передать aggregate, то есть, по сути, disk ownership дисков этого аггрегейта, вместе со всеми томами и данными на них, другому контроллеру в той же HA-паре.

В “Семерке” и 7-mode это делается с остановкой работы контроллера, из boot menu, а вот теперь, использующие Cluster-mode, это могут сделать “на ходу”. Ясно, что для Cluster-mode такая возможность куда более важна, так как в кластере задачи “перекинуть данные”, и, например, полностью вывести контроллер из кластера, допустим для его обновления или замены, это достаточно рядовая задача.

Посмотреть, кому и как назначены aggregates можно командой:
storage aggregate show [-node source-node]

node1::> storage aggregate show
Aggregate Size Available Used% State #Vols Nodes RAID Status
——— ——– ——— —– ——- —— —— ———–
aggr_0 239.0GB 11.13GB 95% online 1 node1 raid_dp, normal
aggr_1 239.0GB 11.13GB 95% online 1 node1 raid_dp, normal
aggr_2 239.0GB 11.13GB 95% online 1 node2 raid_dp, normal
aggr_3 239.0GB 11.13GB 95% online 1 node2 raid_dp, normal
aggr_4 239.0GB 238.9GB 0% online 5 node3 raid_dp, normal
aggr_5 239.0GB 239.0GB 0% online 4 node4 raid_dp, normal
6 entries were displayed.


Собственно процесс релокации аггрегейтов запускается командой:
storage aggregate relocation start -aggregate-list aggregate-1, aggregate-2… -node source-node -destination destination-node

node1::> storage aggregate relocation start -aggregate-list aggr_1,
aggr_2 -node node1 -destination node3
Run the storage aggregate relocation show command to check relocation status.
node1::storage aggregate>

А посмотреть как все идет можно командой:
storage aggregate reloaction show [-node ]

node1::> storage aggregate relocation show -node node1
Source Aggregate Destination Relocation Status
—— ———– ————- ————————
node1
aggr_1 node3 In progress, module: wafl
aggr_2 node3 Not attempted yet
2 entries were displayed.
node1::storage aggregate>

Обратите внимание, что использовать в Cluster-mode старую, disruptive схему, с выключением контроллера, загрузкой в boot menu, снятием там текущего disk ownership с дисков и назначением их новому контроллеру - нельзя. Новые механизмы “по капотом” Cluster-mode, в частности внутренние, реплицируемые между членами кластера базы конфигураций, будут если не повреждены, то уж точно не позволят вам таким образом “релоцированный” мимо штатных механизмов aggregate (и, прежде всего, тома на нем) подключить и увидеть.
Подробно, включая и разнообразный траблшутинг, механизм релокейта рассматривается в документе Clustered Data ONTAP® 8.2 High-Availability Configuration Guide
(https://library.netapp.com/ecm/ecm_download_file/ECMP1196905)

Недавно в одном блоге(внезапно блог этот умер буквально на неделе, поэтому мне пришлось сохраненный текст того поста перенести в документ Google Docs, смотрите содержимое цитируемого поста там) увидел результаты эксперимента, в котором пользователь тестировал FAS3210 на эффект от включенной и выключенной поддержки VAAI, на таких операциях, как создание нового thick eager zeroed диска, клонирование VM, и Storage VMotion.
Я часто встречал какие-то завышенные ожидания от использования VAAI. ?? очень часто люди, не получая ожидаемого ими сногсшибательного результата, начинают думать, что делают что-то не так. А на самом деле этот эффект и правда, по видимому, не слишком велик (по крайней мере не так велик, как о нем думают, и чего ожидают, начитавшись маркетинговых материалов VMware).
Так, например, в рассматриваемом эксперименте, максимальный эффект от поддержки VAAI был на операции Storage VMotion, и представлял собой всего лишь тридцатипроцентное улучшение по времени операции, при пропорциональном увеличении загрузки CPU контроллера.
Сравнивая со сделанными ранее тестами FAS2040, автор вполне резонно делает вывод, что эффект от VAAI, по видимому, тем больше, чем мощнее контроллер, и упирается в контроллер и его процессор. Отсюда вывод, что на entry-level стораджах (любого производителя), эффект от поддержки VAAI в его контроллере, скорее всего незначителен, и нет особого смысла бороться за него, или надеяться на его чудодейственность.

А вот вы знаете, что у нас тут есть русскоязычный форум, с участием же русскоязычных специалистов, работающих в NetApp? Не знали? А он - есть :)
Это я к чему, к тому, что недавно там был обнаружен интересный топик, который будет полезен тем, кто пытается разобраться с непростой темой аггрегации etherchannel и балансировки по нескольким линкам.
https://communities.netapp.com/thread/32967

Если вы занимаетесь NetApp, и при этом еще не там - рекомендую зарегистрироваться (читать можно и так), и подписаться на rss. ??ногда там бывают полезные для жизни темы. Да и возможность спросить на русском тоже бывает порой неоценима.

Как вы знаете (должны знать, по крайней мере), NetApp, вот уже третий год пошел, как владеет бизнесом, ранее принадлежавшем компании LSI/Engenio, и производившим системы хранения “классической блочной архитектуры” для различных OEM-клиентов. Таким образом сегодня NetApp это не только традиционные для него стораджи семейства FAS, то есть unified, NAS+SAN, WAFL-based стораджи “со снепшотами и дедупликацией”, о которых в этом блоге в основном и пишется, но также и “традиционные для рынка” блочные стораджи для FC и iSCSI, которые продает как сам, так и поставляет по OEM-контрактам. Так, например, хорошо знакомые российскому IT системы IBM DS3524 и Dell PowerVault MD3 - это как раз они и есть, NetApp E-series.

Некоторое замешательство вызвало в свое время появление такой, необычной для NetApp, линейки продуктов среди пользователей, как же так, мол, а что же FAS, неужели он теперь не хорош, и вы теперь от него отказываетесь и начинаете заниматься продуктом, всю дорогу с ними конкурирующим?

На самом деле те, кто с NetApp уже давно, они знают, что он, как компания, всегда действует в русле здорового прагматизма, без всякого “идеологического паладинства”, если есть направление, в котором можно заработать деньги - действует простое правило: пойди, дай то, что пользователь хочет, и возьми у пользователя за это его деньги, без всяких “фу, это же не настоящий Fibrechannel!” :). Так, в свое время, NetApp вдруг, неожиданно для всех, перестал заниматься только лишь NAS, и быстро сделал поддержку блочных протоколов SAN в своих системах хранения (оставаясь, впрочем, сторонником своей линии, что NAS есть более интеллектуальный и прогрессивный продукт, сегодня мы все видим, что так оно, во многом, и получилось, смотрите как развивается NAS-направление в виртуализации!).

Точно также получилось и с E-series. На рынке существует ниша, в которой многочисленные интеллектуальные преимущества FAS и Data ONTAP не слишком нужны, а нужна там высокая удельная емкость хранения, высокая линейная скорость записи-чтения, возможность DAS-подключения к серверам, поддержка только блочных протоколов, и так далее. Это, например, системы хранения потокового HD-видео от камер видеонаблюдения, это системы для обработки BigData, например под Apache Hadoop, и ряд других таких же нишевых, но очень деньгоемких систем и областей использования. Ну, вот, отчего не расширить туда присутствие на рынке?

Сперва стораджи E-series продавались только в OEM, потом понемногу NetApp начал производить их и продавать от своего имени, сперва в Америке, а теперь и “в канал”, в том числе и в России.

?? вот, на днях, в семействе E-series вышло большое обновление.
Во-первых, появилась новая линейка в нижнем сегменте, той, чем был тот самый IBM DS3524, он же NetApp E2600. Теперь ему на смену появился E2700.

В линейке будет выпущено три модели, это E2712, E2724 и E2760. Последние две цифры модели, как вы уже поняли, это число дисков в конструктиве. 2712 и 2724 это уже знакомые 2U на 12 и 24 диска 2,5″, а вот 2760 это новый для модели E2 конструктив, уже встречавшийся в семействе E5, это 4U с треями “магазинного” типа, на 60 дисков 3,5″ в корпусе, для “сверхплотных” применений.

Контроллеры E2700 оснащаются в базе портами SAS 12Gb/s, и поддерживают расширение с помощью Host Interface Cards (HIC) с портами FC 16G, iSCSI 10G, а также дополнительными портами SAS 12G.

Будут поддерживаться разные типы дисков: SAS, NL-SAS, а также SSD (кроме 2712). Впрочем, про SSD дальше еще пойдет речь в связи с обновлением All-Flash системы EF5.

В остальном - это наследник E2600, все, знакомое вам по этой модели, в новой осталось.

Обновился контроллер у E5500.

E5500 - это системы еще большей производительности, чем были E2600. Теперь в нем добавились (ранее недоступные) интерфейсы FC 16Gb и iSCSI 10G (ранее были только SAS 12Gb, FC 8Gb и Infiniband). Также как у E2700 будут доступны три конструктива, на 12 и 24 диска в 2U, и на 60 дисков в 4U.
Поддерживаемые диски - SAS и SSD.

Наконец, обновился All-Flash storage, который теперь носит название EF550.

Эта система поставляется в виде 2U корпуса, с вариантами поставки на 12 дисков SSD (9,6TB raw) и на 24 диска SS (19,2TB raw), с общей возможной емкостью системы - 120 дисков.

Поддерживаются интерфейсы:
• 16Gb FC (OM2, OM3, OS1, and OS2 optical)
• 10Gb iSCSI (optical, twinax passive, and RJ-45 Cat 6)
• 6Gb SAS (copper with Mini-SAS cables)
• 40Gb IB (QSFP+ copper and OM3 optical)

Системы поставляются с 800GB SSD дисками технологии SLC, каждый диск оснащен двумя портами ввода-вывода SAS, и имеют пятилетнюю гарантию производителя.
The EF550 ships with 800GB mixed-use multi-level cell (MLC) NAND SSDs from SanDisk with dual (2) full-duplex interface ports. The EF550 actually leverages the dual-active paths from each controller to every SSD as part of its design.
Each SSD is rated at 10 drive writes per day (DWPD), warrantied up to 5 years, but with an endurance lifetime well over 5 years.

??так, долгожданный Virtual Storage Console, основной продукт для интеграции стораджа NetApp и виртуальной инфраструктуры vSphere, добрался до public beta.
Напомню, что VSC 5.0 будет первой версией, с интеграцией в vCenter web client. Вы знаете, что в планах VMware вскоре отказаться полностью от старого, классического “толстого” клиента, и перейти на web-client полностью, уже сейчас все новые фичи добавляются уже только через web-client.
Однако главная проблема тут - в плагинах к vCenter console, например VSC существует пока только для “толстого клиента”. Вот для того, чтобы это исправить, производится переход на новую платформу плагинов, ну и за компанию много всего перетрясено.
Новый VSC радикальным образом переделан и обновлен. Теперь нет отдельного таба для плагинов в клиенте, функции его будут интегрированы непосредственно в дерево inventory. Например для бэкапа датастора нужно будет щелкнуть правой клавишей непосредственно по нужному датастору в инвентори и выбрать нужное действие в контекстном меню.

??з основных особенностей текущей беты:

• VSC требует vSphere 5.5 (но работающие под vSphere 5.5 ESXi 5.х и даже 4.х - поддерживаются)
• ??меет только х64 инсталляцию
• Не поддерживает апгрейд со старой версии VSC (например с действующей 4.2.1)

Специально, отдельной строкой отмечу, что public beta это все же еще не то, что можно ставить на продакшн, по крайней мере как единственный инструмент управления. Но посмотреть уже можно.

В этом году на IT-рынке EMEA появился новый, интересный, и крайне зубастый игрок - Nutanix. В двух словах, это вычислительная кластерная платформа, позволяющая строить фермы виртуальных машин без использования SAN-хранилищ, это “сервер-и-сторадж”, интегрированный специальной IT-магией в единый “кирпичик”, из множества которых можно строить кластеры VM, легко масштабируемые.
Так уж получилось, что активное продвижение Nutanix на российском рынке постоянно сталкивает его с системами NetApp, и кастомеры довольно часто задают такой вопрос “А если слон на кита залезет, то кто кого сборет?” “Победит ли Nutanix NetApp, или наоборот?”

Поэтому вопрос, заданный в заголовке, имеет ответ, что они, конечно, конкуренты, но лишь на определенном участке рынка, таким образом, можно представить пересечение множества задач обоих вендоров в виде классической диаграммы окружностей пересечения множеств (для политкорректности я намеренно показываю размер окружностей равным ;)

Да, есть области у Nutanix и у NetApp, в которых они встречаются на рынке. Но и у того и у другого продукта область применения куда шире, чем то, чем они пересекаются. Вот почему я считаю, что Nutanix и NetApp - не являются взаимно конкурирующими продуктами, я уверен, что на рынке есть место как для одного, так и для другого. В этом блоге мы рассмотрим вопрос, почему Nutanix - не конкурент NetApp.

1. Nutanix - это решение для виртуализованных сред. Область применения NetApp гораздо шире. Nutanix - передовая платформа крутить гипервизор виртуализации, это, если угодно, server-oriented система. Это сервер, с некоторыми функциями хранилища, интегрированными в него. NetApp - это, наоборот, “хранилище-ориентированная” система, это сторадж, в который интегрированы некоторые функции сервера (NAS, репликация). Эти две системы идут “навстречу”, и вот, на каком-то нейтральном для них обоих поле, они встретились и пересеклись.
На этом (и только на нем) можно говорить о конкуренции.

2. Передовые технические решения это здорово. Но иногда хочется оставаться в рамках классических архитектур. Например, когда переход на новую архитектуру несет с собой существенные риски и затраты на полную переделку уже существующей, работающей и приносящей деньги системы. Которую обслуживают люди, с определенным уровнем квалификации, в которую вложены деньги через их обучение. Которая обвязана разнообразными работающими “3rd party” продуктами, такими как инструменты мониторинга, алертинга, оптимизации, аналитики. ?? которые просто с точки зрения защиты инвестиций нельзя просто взять и выкинуть (и купить новые).

3. Линейное масштабирование, о котором часто говорит Nutanix, работает только для определенного ряда задач. Это фермы веб-сервисов, это VDI-среды, это некоторые NoSQL и BigData приложения. Это там, где сама задача позволяет выполнять обработку своих данных параллельно. Это, однако, не работает для “классических” SQL-баз и ряда традиционных архитектур. А это, читай, биллинги, ERP, legacy-системы, и все такое прочее. Перенос с переписыванием таких приложений под масштабируемую архитектуру съест всю гипотетическую экономию и поэтому экономически бессмысленнен.
Если ваша задача не масштабируется и не параллелится на кластер нодов и мощность одного нода для нее недостаточна, то никаких способов увеличить производительность этой задачи, крутя ее на Nutanix, у вас нет. В наше время это не слишком частая ситуация, тем не менее это все еще встречается.

4. Существует ряд задач, связанных с чистым хранением (а не хранением ?? обработкой) больших объемов данных. Если вам нужно хранить массив данных в несколько сотен терабайт, причем в основном только хранить, то хранить его на вычислительных нодах, тем более таких недешевых и производительных, как старшие Nutanix (NX-6000) - это оверкилл.

5. NetApp, во многих случаях, выбирают ради его многочисленных сервисов хранения данных (FlexClone, SnapLock, компрессия и дедупликация данных), их защиты, интегрированных в приложения (SnapManager, SnapProtect, SnapCreator) и репликации (SnapMirror, Metrocluster). Nutanix пока такими возможностями не обладает.

6. Если ваша задача может быть уложена в, порой прокрустово, ложе серверной виртуализации - отлично. Если нет - Nutanix с этим не работает. К сожалению, до сих пор многие важные для отрасли производители софта крайне настороженно относятся к попыткам кастомеров переносить их системы с физических платформ в виртуальные машины, и, часто, не поддерживают штатным образом такие конфигурации (пример - Oracle, а значит, сразу, любые системы, его использующие).

Ну и остановимся пока.
Таким образом, как вы видите, Nutanix конкурирует не с NetApp как таковым. Он конкурирует, возможно, с NetApp/Cisco FlexPod. Но FlexPod - это совсем не весь NetApp, это лишь отдельный прикладной продукт для определенного рынка, использующий систему хранения NetApp как свой компонент.

Можно сказать даже более, в каком-то смысле ?? Nutanix, ?? NetApp местами даже играют вместе, в одной команде. Одной из ключевых тем push message у Nutanix есть тезис об устарелости и неэффективности SAN и использования LUN, шире - тупого “блочного доступа”, прежде всего для виртуализованных сред.
Но так ведь и NetApp продвигает эту идею ни больше, ни меньше как с 1993 года! Да, NetApp умеет SAN вместе с NAS c 2004 года, в рамках концепции Unified Storage, и умеет крайне неплохо, но тем не менее, с самого начала своего сотрудничества с VMware он всюду твердит, что SAN LUN это вынужденный метод для размещения датасторов виртуальных машин, что VMFS - костыль, красивый, сияющий, хайтек, но - костыль. Что NAS-концепция и NAS-протокол лучше чем что-либо подходит именно для такого применения (параллельного доступа к данным на дисках от разных его потребителей со стороны хоста). “Делаете облачный сторадж - выкиньте LUN-ы!” - пишет в своей колонке в Computerworld Джон Мартин, директор SNIA ANZ и главный специалист по технологиям в австралийском NetApp. ?? все это как нельзя лучше поддерживает и перекликается с тем, что говорит по этому поводу Nutanix.

У NetApp есть такой подсайт, который называется Hardware Universe. На нем собраны разнообразные материалы по аппаратной части систем, например матрицы совместимости контроллеров и плат расширения, и прочие такие же полезные штуки. К сожалению, для доступа туда нужен, как я понимаю, партнерский аккаунт. На этом сайте можно найти, например, PDF с таблицами характеристик контроллеров и их максимумов. Например, какого размера данный контроллер поддерживает том для дедупликации, сколько LUN-ов можно создать максимально, какая минимальная версия Data ONTAP для этого контроллера нужна, или какое его тепловыделение в BTU, и так далее.

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

Maximums for 8.2 7-Mode

Maximums for 8.2 Cluster-mode

Maximums for 7.86 SANtricity (E-series)

??нтересный способ был подсмотрен в соседском блоге.

В некоторых (нечастых) случаях возникает необходимость преобразовать уже существующий виртуальный диск, например файл VMDK, лежащий на NFS-шаре, в RDM LUN (RDM – raw device mapping, подключение физического LUN в VM непосредственно, как SCSI LUN-а). Есть некоторое ограниченное число случаев, когда трудно или нельзя обойтись без RDM.

Сделать это можно без необходимости копирования данных через хост и создания второй копии данных. NetApp может создать LUN с указанием файла на диске, из которого будет взято его содержимое. При этом со стороны хоста это будет самый настоящий физический SCSI LUN, и его можно будет подключить как самостоятельное физическое устройство, например с помощью установленного внутри VM OS инициатора, допустим MS Software iSCSI Initiator, как новый диск. Но при этом на стороне стораджа такой “LUN” будет просто небольшой ссылкой на данные соотвествующего vmdk, уже хранящегося на дисках.

Опция –f может указать при создании LUN файл, хранящий содержимое сотвествующего LUN-а.

lun create -f /vol/vol1/test02/test02_1-flat.vmdk -t windows_2008 /vol/vol1/lun1
создаст физически небольшой файл LUN  /vol/vol1/lun1 (тип LUN – windows_2008), указывающий на существующий .vmdk файл test02_1-flat.vmdk. В дальнейшем вы можете работать с таким “LUN”-ссылкой как с настоящим LUN-ом.

Обратите внимание, что в качестве vmdk указан именно *-flat.vmdk, большого размера.

Помните также, что после такого “преобразования” нельзя удалить этот *–flat.vmdk, так как именно в нем будет находиться физическое содержимое LUN.

Сложно сказать, насколько такой вариант пригоден для продакшна, и насколько он беспроблемен с точки зрения производительности, но как вариант сделать это быстро, и для тестовых системм он, конечно, незаменим.

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