Pull to refresh
0

Лучшая система хранения под VMware (а также Hyper-V, Xen, KVM, etc)

Reading time13 min
Views30K

В предыдущих постах этого блога я постепенно рассказал про наиболее значимые возможности систем хранения NetApp, пришла пора разбавить сухую теорию практическими делами. Здесь и далее я собираюсь писать о том, как все эти фенечки работают для тех или иных решений, для виртуальных инфраструктур, баз данных, высокопроизводительного файлового сервиса и прочих традиционных областей применения NetApp.
Я отдаю себе отчет в некоей провокативности заголовка, однако постараюсь защитить свою позицию текстом статьи. Если же вы придерживаетесь другого мнения о «идеальном» хранилище для VMware ESX, или, шире, для любого средства серверной или десктопной виртуализации, то буду рад обсудить это в комментариях.

Хотя системы серверной и десктопной виртуализации и не являются единственным рынком систем хранения NetApp (например в этом году Ларри Элиссон сделал нашумевшее заявление, что, по его сведениям, до 60% бизнеса NetApp это хранение баз Oracle (рус.)) но таков нынешний тренд рынка, что продукты VMware, MS Hyper-V, Xen, и аппаратные решения под них — это самый передовой, технологичный и быстро растущий сегмент программного и серверного рынка. Ничего удивительного, что NetApp им так плотно занимается почти с самого момента появления этой отрасли на свет. Ведь так получилось, что идеи и принципы, заложенные в системах хранения NetApp удивительно хорошо совместились технологически с тем, что сейчас делают вендоры систем виртуализации в своей области.

Прежде чем мы начнем рассматривать подробно основные «фишечки» NetApp в этой области, давайте просто перечислим то, что является самыми интересными и «цепляющими» возможностями систем хранения NetApp, конкретно в этой области (линки ведут на предшествующие статьи на Хабре, посвященные рассказу об этой возможности).


Рассмотрим же в чем эти потенциальные возможности системы хранения становятся реальными преимуществами для виртуальных систем.

1. Возможность использовать для подключения дискового хранилища к серверу ESX, для размещения на нем его данных по протоколу NFS появилась в VMware еще в версии 3.0, но увы, до сих пор этот вариант подключения хранилищ, особенно для новичков, представляется чем-то необычным (и «непонтовым», в отличие от FC;). Люди же опытные давно распробовали и используют этот вариант, в качестве масштабных примеров могу привести опыт таких гигантов, как T-Mobile (крупнейшая в мире «облачная» система хостинга SAP, около 2 миллионов клиентов), Oracle, SAP, Deutsche Telecom, Rackspace, и множество других, не таких «транснациональных», которые используют NFS как основной протокол передачи данных от дисковой системы хранения к серверам и гипервизорам. По оценке аналитиков консалтинговой компании Forrester, NFS, как протокол доступа к хранилищам данных серверов VMware, стабильно растет по распространенности и популярности, достигая на сегодня 36% (18% два года назад), и уже обогнал по популярности iSCSI.



Среди многочисленных преимуществ использования NFS в VMware (я думаю, что этой теме позже я посвящу отдельную, развернутую статью) следует назвать такие интересные возможности, как:
  • Возможность создавать куда большие, чем с использованием VMFS, датасторы (до 16TB одним куском).
  • Возможность датасторы не только расширять (что позволяет VMFS), но и сжимать (что VMFS не позволяет, а часто требуется, в динамически распределяемых «облачных» средах), причем с шагом всего 4KB.
  • Высокая гранулярность. В отличие от датастора на VMFS вы можете оперировать (например сохранять в резервную копию и восстанавливать из нее) не датастором целиком, а отдельным виртуальным диском отдельной виртуальной машины, или же ее конфигурационным файлом. Это очень удобно, если вы используете большой датастор с десятками и сотнями машин на нем.
  • Thin by design. «Виртуальные диски» виртуальных машин на датасторе по NFS это обычные «файлы» на сетевой «шаре». Они занимают столько места, сколько в них фактически написано данных, а не столько, сколько мы зарезервировали при их создании. Терабайтный VMDK, в который записано пока только 3GB, займет на системе хранения только 3GB места.
  • Дедупликация, о которой подробнее ниже (и выше;) ранее в блоге), высвобождает место, которое становится непосредственно доступно ESX-серверу, и на котором он может сразу же размещать свои новые данные. Дедупликация для LUN-ов с VMFS также высвобождает место на системе хранения, однако оно не становится немедленно доступно виртуальной машине.
  • Наконец, подключение и работа с NFS осуществляется по всем знакомому и привычному Ethernet, не нужно городить отдельной, специальной и дорогостоящей инфраструктуры FC, с использованием Gigabit и 10G Ethernet вы можете оставаться в привычной (и недорогой) Ethernet-инфраструктуре, а разница в производительности с FCP и iSCSI, как показывают результаты самой VMware, незначительна.
  • Нет проблем с ограничением на размер очереди SCSI-команд и SCSI lock (что особенно важно для больших, динамически конфигурируемых систем «облачного» типа, использующих сторадж без поддержки VAAI, которая, напомню, есть только в самой «топовой» лицензии VMware Enterprise Plus).

Однако преимущество универсального, мультипротокольного хранилища (unified storage) заключается еще и в том, что решение использовать, например, NFS вам не навязывается. Система хранения типа unified storage может работать по любому из имеющихся у нее протоколов доступа к данным. Вы можете использовать _любой_ имеющийся протокол, более того, любой набор протоколов одновременно. Если у вас есть необходимость использовать «блочные» протоколы, для LUN (например, вам необходимо использовать RDM), вы можете взять для этого FCP или iSCSI, хотите NFS — используете его, одновременно с первыми, на одной и той же системе хранения.
К примеру вполне интересным может быть вариант использовать подключение по FCP или 10G iSCSI для нескольких особопроизводительных и критичных VM, iSCSI по Gigabit Ethernet и VMFS для других, не столь «грузящих» VM, но желающих работы по блочному протоколу, а на NFS сделать большое хранилище (до 16TB в датасторе), например для десятков или даже сотен сравнительно слабонагруженных по вводу-выводу VM. Совершенно неоценимая в реальной жизни гибкость.



2. Наверное одной из самых популярных и эффектных возможностей систем хранения NetApp под виртуальные среды (не только под VMware ESX, но и под VMware View (VDI), под MS Hyper-V и Citrix Xen) является возможность дедупликации данных, то есть удаления из них многократно повторяющихся фрагментов. Дедупликация особенно эффектно работает в случае виртуальных сред, ведь очевидно, что большая часть файлов виртуальных дисков для виртуальных машин будет содержать одну и ту же OS, с одними и теми же, или очень похожими файлами в них.
По этой причине дедупликация датасторов может дать 50% и более (на практике встречаются результаты и до 75-85%!) экономии пространства. То есть после дедупликации хранилища его доступный объем словно бы увеличивается для вас вдвое-втрое!



Особенно приятно, что вам не придется за это платить снижением быстродействия. В подавляющем большинстве случаев пользователи, после дедупликации, не видят никакого заметного на глаз снижения быстродействия их хранилищ.
Но уменьшение объемов хранения на дисках это лишь одна выгода. Весьма важным и интересным также является то, что дедуплицируются при этом еще и данные в кэше!
Представим себе систему хранения, хост-сервер, подключенный к ней считывает блоки данных, которые попадают в кэш, сколько в него поместится, а остальные, не попавшие, медленно читаются с дисков (cache miss).



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



В отличие от «обычного стирального порошка стораджа», для которого все блоки на дисках уникальны и неотличимы друг от друга, и даже блоки полностью идентичные по содержимому будут занимать место в кэше при считывании (классический сторадж ничего не знает о содержимом блока, для него это «блок номер три», «номер пятьсот сорок» и «номер стотыщпицот»), система NetApp знает, что блок подвергался дедупликации, и на три команды считывания от хостов можно считать с диска в кэш и отдать хостам всего один блок, идентичный содержимым всем трем запрошенным.

Таким образом, уменьшив вдвое и более объем хранения на дисках, за счет дедупликации и совместного использования блоков хранения (block sharing technology), мы вдвое и более уменьшаем объемы занятые этими блоками в кэше, то есть, виртуально, получаем эквивалентный объем кэша на такой системе вдвое и более емкий. Ведь теперь у нас идентичные блоки не дублируются не только на дисках, но и в памяти кэша.
«Вот тебе и вторая выгода» — как говорил в известном мультфильме удав слоненку про его хобот.

3. Ситуация с экономией места, и виртуальным увеличением емкости кэша становится еще более полезной, так как NetApp активно использует свою сравнительно недавнюю придумку, о которой я уже писал на Хабре — так называемый Virtual Storage Tiering с помощью большого кэша на flash-памяти.
Такой кэш как нельзя лучше решает весьма болезненные для виртуальных инфраструктур проблемы boot storm, login storm (представьте себе большую компанию, использующую VMware View или аналогичный десктопный продукт, и работники которой одновременно включают в 9 утра тысячи рабочих мест), а также все прочие «штормы», так как рабочий (и дедуплицированный) набор данных, зачастую, с запасом помещается в такой «мегакэш» и примерно на порядок (в 10 раз) уменьшает время задержек (так называемую latency) и производительность системы хранения.



Немаловажной особенностью также является и экономия ресурсов, электропитания, охлаждения и места стойке. Ведь набитая дисками полка занимает 4U в стойке, потребляет около 340 ватт/час и 1400 BTU/час тепла, а плата Flash Cache, которая может обеспечить быстродействие нескольких таких полок, потребляет 18 ватт/час, не занимает место в стойке, выделяет всего 90 BTU/час тепла. Для значительных по размеру систем это может быть очень и очень существенная экономия.



4. Thin Provisioning, о котором я уже рассказывал ранее, как нельзя лучше подходит для задач «облачного» хранения, в особенности для задач, когда занятый объем может произвольно и слабопредсказуемо увеличиваться, а количество клиентов, использующих хранилище десятки и сотни. Выделяя таким клиентам место на дисках динамически, используя overprovisioning, то есть модель, когда клиент «видит» свободное место в том размере, в котором его затребовал, а на дисках системы хранения занимает только в том объеме, сколько фактически записано данных на диски.



При этом хотелось бы отметить, что разницы в производительности между thin и thick дисками для VMware практически нет. Также на практике равно нулю влияние «фрагментации» при таком «растущем» при записи диске.
Обращу ваше внимание также и на то, что «аппаратный» thin provisioning в системах хранения может работать не только с thin-дисками VMware, но и с thick- (исключая eager zeroed thick). И если вы, по какой-то причине, не хотите или не можете использовать собственный thin -механизм VМware, или же используете гипервизор не-VMware, в котором механизма thin-disk еще нет, вы по прежнему можете получить все возможности thin provisioning, так как они реализуются для вас независимо, системой хранения.

5. Я уже рассказывал о том, что такое снэпшоты, и как их используют NetApp. Вы, уверен, уже знаете, что это, и насколько удобно таким образом создавать мгновенные копии и восстанавливать из них состояние данных на нужный вам момент. Однако, как возможно вы знаете, у VMware есть свой собственный механизм создания снэпшотов на уровне датастора. Но те, кто уже попробовали, отзываются он нем не лучшим образом. Действительно, как, надо заметить, многие попытки реализовать снэпшоты в системах хранения или софте получались не очень удачными, с большим количеством неприятных побочных эффектов, такими как снижение производительности при использовании, а в случае VMware — куча сложностей при их удалении. В общем, должен присоединится к мнению известного российского специалиста по VMware, Михаилу Михееву: «Снэпшоты — это зло», но с одной поправкой: «Снэпшоты VMware — это зло», потому что снэпшоты средствами стораджа NetApp — это совсем другое дело ("… — добро";). И вот почему.

За счет использования механизмов WAFL получающиеся снэпшоты не только не замедляют работу хранилища, но и решают описанную проблему с работой снэпшотов в VMware, что позволяет использовать их максимально широко не только для «фиксации» тех или иных состояний виртуальных машин, но и как полноценные резервные копии.
Для этого имеется специальный программный продукт — SnapManager for Virtual Infrastructure, который берет на себя все задачи создания консистентной копии содержимого датастора VMware, и восстановления из такой копии датастора или его части.



Собственный механизм снэпшотов хранилища работает интегрированно со снэпшотами VMware таким образом, что когда система хранения создает снэпшот, то, для обеспечения консистентности файловой системы и состояния VM (операции ввода-вывода на момент взятия снэпшота надо приостановить), она вызывает механизм снэпшота VМware, приостанавливая на доли секунды работу гипервизора на данном датасторе, делает снэпшот, и освобождает гипервизор, фактически не создавая «нехороший» снэпшот VМware, а используя только беспроблемный «аппаратный» снэпшот системы хранения.

6. FlexClone. Можно дедуплицировать дублирующиеся данные, а можно просто не допускать дубликатов, у NetApp это даже называется термином non-duplication, «не-дуплицирование». Та же технология «shared blocks», которая испольщуется в дедупликации, когда на один физический блок могут ссыллаться сотни «логических» блоков файловой системы, использована в фиче под названием FlexClone.

image

Технология отчасти сходна с технологией Linked Clones, но работает для любых задач, так как реализована собственно самим стораджем.
При создании клона данных (тома, LUN, файла) не копируется его содержимое в новый экземпляр, а создается новая копия метаданных, указывающая на прежние блоки данных, а вот измененные, по сравнению с оригиналом, блоки, уже займут место, но только они. Получается такая реализация «дифференциальных дисков».

image

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

image

7. Приятно, что почти все перечисленные возможности системы хранения NetApp доступны из интегрированного в vCenter специального «центра управления» системой хранения. Теперь администратор VMware может не прыгать между двумя и более инструментами управления, отдельно для стораджа, в его собственном виде, отдельно для VMware в vCenter. Теперь все управление сосредоточено в vCenter.
Эта панель-страница интегрируется в vCenter, и бесплатно доступна для всех систем хранения NetApp. Кроме того, с данным инструментом поставляются специальные средства, которые автоматически оптимально установят, например, настройки multipathing, таймауты SCSI и прочие необходимые параметры в соответствии с вендорскими Best Practices.





8. Наконец, совсем бегло, стоит упомянуть про интересные возможности secure multitenancy, то есть возможности, при необходимости такого, поделить систему хранения на несколько «виртуальных», независимых «подсистем хранения», например если вы в организации вынуждены, предположим по требованиям внутренней политики безопасности, разграничивать хранилища и такая политика требует абсолютной изоляции (даже для администратора!) разделов, допустим, HR или финансового департамента, от администраторов других отделов. Теперь физически одна система хранения может работать в таком «логически разделенном» виде.
Системы хранения NetApp также одними из первых реализовали поддержку VAAI, позволяющего часть задач с сервера гипервизора передавать на выполнение на систему хранения, например создание и заполнение нулями разделов, копирование разделов, или новую, более «гранулярную» систему SCSI-локирования, и таким образом повысить производительность в больших инфраструктурах.
Кроме того NetApp разрабатывает и производит очень интересный инструмент анализа и оптимизации производительности виртуальных инфраструктур OnCommand Insight (бывший Akorri BalancePoint), который доступен и независимо от систем хранения NetApp, тут я его упоминаю «чтобы два раза не вставать», для тех, кто осилил этот мой сегодня неприлично огромный текст. :)

Итак, резюмируя в заключение:
Я считаю, что системы хранения NetApp есть естественный и лучший выбор сегодня для любых сред виртуализации, например для VMware vSphere, VMware View, MS Hyper-V, Citrix Xen, и других, так как предлагают разом несколько важных и удобных возможностей:

  1. Мультипротокольность — то есть работу по нескольким различным протоколам доступа: FC, iSCSI, NFS, причем одновременно, без необходимости делить систему хранения или данные на ней, и обращаясь к данным общим, единообразным образом.
  2. Дедупликация — позволяет сэкономить место на систем хранения, сократив от половины и более занятого места за счет процесса устранения дублирующихся фрагментов, например файлов в виртуальных дисках vOS, не поступаясь производительностью, а кроме того, может быть, даже и увеличить ее за счет виртуального увеличения емкости dedupe-aware кэша.
  3. Thin Provisioning — облегчает администрирование, экономит дисковое пространство и позволяет удобнее распределять место задачам «по облачному».
  4. Flash Cache — увеличивает производительность работы за счет использования flash-памяти для организации эффективного слоя «кэша» хранения самых «горячих» блоков данных на пространстве flash, не используя при этом капризные и дорогие SSD.
  5. Snapshots — позволяет почти мгновенно создавать «снимки» состояния данных, создавать с них резервные копии, и моментально восстанавливать из них виртуальные машины, не жертвуя производительностью и не занимая непроизводительно пространство на хранилище под эти «снимки».
  6. FlexClone — создает на хранилище «идеальные клоны» данных, например дисков виртуальных машин или пользовательских данных, которые занимают на диске данные только в объеме изменений по отношению к «оригиналу» клона, что позволяет хранить сотни объемных клонов на незначительном пространстве.
  7. VMware Storage Console — позволяет удобно администрировать систему хранения во встроенном в интерфейс vCenter приложении-страничке и автоматизировать ряд рутинных процедур, а также автоматически оптимизировать критичные настройки системы хранения для наилучших результатов, и дать возможность администратору VMware самому управлять рядом разрешенных ему параметров хранилища VMware ESX, не отвлекая на такие пустяки администратора системы хранения.
  8. Использовать еще ряд вкусностей, таких как secure multitenancy (возможность безопасно для пользователей разделить систему хранения на изолированные «виртуальные файлеры»), VAAI, и так далее, о которых я почти ничего не рассказал, чтобы не делать эту статью совсем уж бесконечной.

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

Таким образом, за цену, сравнимую с ценами аналогичных систем хранения других производителей вы получаете систему с бОльшими возможностями по подключению за счет поддержки разных протоколов, с большей надежностью и защитой за счет RAID-DP и снэпшотов, с большей производительностью за счет Flash Cache, и с большей емкостью, за счет дедупликации, FlexClone и thin provisioning.

Так что, мне кажется, что если вы имеете планы развертывать виртуальную серверную инфраструктуру или «облачную» систему, и уже наметили себе систему хранения того или иного производителя, то, прежде чем делать выбор, имеет смысл повнимательнее познакомиться с системами хранения от NetApp, тем более, что в большинстве случаев вам не придется покупать «кота в мешке», ведь у большинства компаний партнеров NetApp вы можете получить ту или иную систему в «триал», для оценки ее возможностей непосредственно «на железе», в конкретно вашей задаче. Попробовать, покрутить, погонять на нагрузке, и решить, то ли это, что вы ждете.
Список компаний-партнеров, к которым, среди прочего, следует обращаться с традиционным для этого блога вопросом «сколько стоит» ;), а также за «тестдрайвом», можно посмотреть на официальном сайте NetApp на русском языке.

Вот почему я называю системы хранения NetApp «идеальным выбором для VMware» (а также Hyper-V, Xen, KVM, и так далее). А как считаете вы, какой возможности в вашей системе хранения не хватает, чтобы считать ее «идеальным решением под виртуализацию»?
Tags:
Hubs:
+14
Comments85

Articles

Change theme settings

Information

Website
www.netapp.com
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия