Posts tagged ‘vmware’

Data ONTAP Edge-T

Совсем немного времени прошло с момтента выпуска Data ONTAP Edge – “виртуального NetApp” в форме Virtual Appliance для VMware, как подоспел “апсайз”: Data ONTAP Edge-T.

Если кратко, то это расширенная и углубленная версия Edge:

Кк видите, теперь Edge может быть не только источником данных для SnapVault, но и получателем (в том числе для серверов с Open System SnapVault, под “обычными” OS), поддерживает репликацию SnapMirror. Остальные параметры остались без изменений.

Если вы уже интересовались ценами на Edge, то уже, наверняка были удивлены фактом того, что Edge продается в одном варианте - паком на 10 лицензий (UPD: с сентября можно купить поштучно). То есть нацелен он, прежде всего, на множественные филиалы, но цена, из-за за 10 штук, получилась не очень интересной тем, кому хочется купить и использовать всего один-два. Ждем более интересной и подходящей ценовой политики от Edge-T.

Берут “на попробовать” по-прежнему там: http://www.netapp.com/data-ontap-edge-eval

NetApp MetroCluster целиком сертфицирован под VMware

Я уже писал тут о NetApp MetroCluster, решении построения распределенного отказоустойчивого хранилища данных с “нулевым RPO/RTO”.

Этот продукт уже довольно давно был сертифицирован на совместимость по программе VMware vMSC (vSphere Metro Storage Cluster), но только как NFS хранилище, и включен в такой конфигурации в VMwatre HCL. Однако недавно была завершена и сертификация решения под блочные (iSCSI и FC) протоколы, и сейчас NetApp MetroCluster – единственное среди систем хранения в листе vMSC стораджевое решение географически распределенного кластера, сертифицированное по программе vMSC под блочные (iSCSI, FCP) и файловые (NFS) протоколы вместе, как в stretched-версии (до 500 метров разноса узлов), так и в switched (до 100 километров между узлами).

Про NetApp Metrocluster теперь есть статья в VMware Knowledgebase: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2031038

Так что прошу любить и жаловать. Если вам нужно распределенное отказоустойчивое хранилище под задачи VMware vSphere, причем гарантированно поддерживаемое VMware, то обратите внимание на NetApp MetroCluster. Это недешевое решение, разумеется, но, в тех случаях, когда отказ и недоступность данных на хранилище недопустим абсолютно, это одно из наилучших решений в этой области, хорошо практически отработанное, существующее на рынке уже около 10 лет, и используемое в продакшне сотнями разнообразных клиентов NetApp в мире.

image

VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

 

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

VMware и использование NFS: часть 3c – Трафик NFS в разных подсетях

Продолжаем публикацию переводов серии постов в блоге Wahl Network, посвященных вариантам использования NFS в VMware.

NFS в vSphere – погружение в детали: часть 2, порты vmkernel и экспорты NFS в разных подсетях

Apr 27, 2012

Ранее мы уже рассмотрели некоторые ошибочные концепции относительно NFS в vSphere, а также убедились в том, как трафик NFS идет при использовании одной подсети. Сейчас давайте посмотрим, как трафик NFS в vSphere пойдет в случае использования множественных подсетей. Хотя мы говорим тут прежде всего о NFS, это все также применимо и в случае iSCSI, если для него не используется binding.

Continue reading ‘VMware и использование NFS: часть 3c – Трафик NFS в разных подсетях’ »

VMware и использование NFS: часть 3b – Трафик NFS в одной подсети

Для рассмотрения вопроса, как работает доступ к стораджу по NFS с хоста ESXi, я снова воспользуюсь серией постов блога Wahl Network, переводы которых я публикую сегодня и в ближайшие несколько дней. Его автор провел экспериментальную работу, показав то, как работает NFS в сети хранения, когда датасторы и vmkernel расположены в одной общей подсети, в разных подсетях, и рассмотрел вариант использования Load-based teaming, доступный для пользователей версии vSphere уровня Enterprise Plus.

Я надеюсь, что эти статьи ответят на вопрос, как же все же работает NFS в сети хранения vSphere, и как стораджи с использованием этого протокола правильно использовать для VMware vSphere 5.0.

NFS в vSphere – погружение в детали: часть 1, порты vmkernel и экспорты NFS в единой общей подсети

Apr 23, 2012

Конфигурация

Для эксперимента, показывающего, как vSphere направляет трафик NFS в одной подсети, я создал тестовый стенд, с использованием 2 серверов NFS (я использовал для этого NetApp Simulator) с каждого их которых выведено по 2 экспорта, суммарно 4 экспорта NFS. Весь трафик направлен в VLAN 5 (это подсеть 10.0.5.0/24 моего стенда) и идет на хост ESXi 5.0 update 1 (build 623860). Хост имеет 2 физических порта-аплинка и 4 порта vmkernel, дающих трафику NFS множество возможны путей. Для того, чтобы создать существенный трафик в сети хранения, я развернул 4 VM с VMware IO analyzer appliance – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

VMware и использование NFS: часть 3а –Балансировка нагрузки по NFS

Как вы помните, я обещал остановиться на вопросе как именно правильно настраивать работу NFS по нескольким физическим интерфейсам Ethernet. ??так, отдельный разоблачения заблуждений в отношении multipathing для NFS псто!

Как я уже вкратце показал, широкораспространенное заблуждение, что, использовав NFS, вы будете вынужденно ограничены ровно одним интерфейсом ethernet, так как “NFS не поддерживает multipathing” – не верно. К моему глубокому сожалению, это заблуждение местами поддерживает даже сама VMware, несмотря на то, что метод балансировки с помощью нескольких портов VMkernel и нескольких IP-алиасов описан и рекомендуется в их же Best Practices.

Я уже написал ранее, что принципы работы NFS таковы, что даже пустив трафик Ethernet по нескольким объединенным в etherchannel портам, вы не добьетесь не только равномерной их загрузки, но даже не загрузите порты кроме первого. Это по видимому связано с тем, что NFS образует ровно одну TCP/IP сессию для данной пары IP-адресов “источник-приемник”, и именно ее и пускает по первому же подходящему для этого порту. А одну сессию разбить на несколько интерфейсов нельзя. Видимо именно это явилось источником странного заблуждения, что трафик NFS нельзя распределить по нескольким интерфейсам. Это не так, можно. Но нужна некоторая хитрость, в общем-то очевидная. Нужно создать несколько пар IP “источник-получатель”, в разных подсетях, и их уже распределить по интерфейсам.  Об этом подробнее далее в постах серии.

Впрочем, как вы уже видите, неверно и обратное убеждение. Совсем недостаточно объединить несколько портов в etherchannel (у NetApp он называется VIF или ifgrp), чтобы, автоматически, увеличить пропусную способность получившегося интерфейса в Х-раз.

Давайте разберем некоторые распространенные заблуждения на этот счет:

1. Трафик NFS можно назначить на порт VMkernel также, как мы назначаем его для iSCSI.

Это не так. К сожалению.

Как вы видите на рисунке, в обведенном оранжевой рамкой боксе, можно назначить данный порт для: iSCSI, FT, Management или vMotion. Но не для NFS. Трафик NFS пойдет по первому же порту, принадлежащему подсети IP-получателя. Если порта в подсети IP-получателя трафика нет, то трафик пойдет через порт Management, в направлении его default gateway (предсказуемо), и такого варианта следует всеми силами избегать.

2. Трафик NFS равномерно распределяется по всем аплинкам (физическим vmnic) хоста, используемым для связи с системой хранения.

Увы – нет. Когда ESXi нажодит и выбирает подходящий порт vmkernel (принцип выбора описан выше), следуюшим шагом он выбирает аплинк. Независимо от типа vSwitch, хост vSphere использует конфигурацию portgroup по умолчанию (только с использованием virtual port ID), и, при наличии нескольких активных аплинков в группе, будет выбран только один (первый подходящий) аплинк для трафика NFS к данному примонтированному экспорту. Порты в группе при этом работают на поддержку high availability, то есть при выходе из строя активного порта, трафик перейдет на ранее пассивный порт, но не для load balancing, то есть трафик NFS по портам vmnic в группе не распределяется.

3. Достаточно включить несколько физических портов на стороне стораджа в VIF (etherchannel), и трафик магическим образом распределится по всем им, расширяя полосу пропускания интерфейса в Х-раз.

Тоже, к сожалению, в общем случае, без дополнительных усилий, неверно. При наличии одной TCP/IP сессии NFS с одного IP-источника на один IP-получатель, нельзя “разложить” трафик на несколько портов. Но можно это сделать для нескольких портов, нескольких IP-алиасов для получателя и/или  нескольких портов VMkernel. Тогда, создав, например 4 пары IP в разных подсетях, для четырех eth, можно гораздо более равномено загрузить их работой. Это не столь “магически-автоматически”, но это работает. Без такого разбиения и распределения  etherchannel обеспечивает только отказостоустойчивость (при отказе активного порта, трафик перенаправится в другой, ранее неактивный, в той же группе), но не балансировку нагрузки и не расширение bandwidth.

На стороне хоста ESXi для использования балансировки вам необходимо создать static Etherchannel с IPhash-based teaming policy, и иметь у vmkernel IP уникальный, между другими vmk, так называемый least significant bit.

Если у вас на VMware лицензия Enterprise Plus, и вы используете vSphere Distributed Switch, вы также можете воспользоваться Load-based Teaming для распределения трафика по VLAN или подсетям. При этом вам также понадобятся несколько VLAN или подсетей на VIF стораджа. Подробнее о таком варианте – в одном из следующих постов.

VMware и использование NFS: часть 2

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

??так, перейдем к некоторым конкретным вопросам, на которые приодится отвечать, выбирая NFS в качестве протокола доступа к датастору в VMware. Впервые такой вариант появился еще в VMware ESX 3.0, и постепенно зарабатывает все большую популярность, потесняя “классический” блочный способ подключения по FCP или iSCSI. О преимуществах, и некоторых недостатках я писал в первой части данной серии.

Какие же основные проблемы принято называть, когда речь идет о испоьзовании NFS для VMware?

1. На NFS нет multipathing.

?? значит, выбирая NFS, я ограничен производительностью только одного интерфейса Ethernet” добавляется явно или подразумеваемо. Ну, на самом деле это “и так и не так”. Пока оставим “за скобками” практическую надобность расширения канала к дискам даже для Gigabit Ethernet NFS или iSCSI (во многих системах это расширение bandwidth имеет довольно спорную практическую ценность). На NFS действительно нет multipath в том виде, в котором он понимается в блочных протоколах, потому что multipathing (MPIO, Multipathed Input Output) – это фича исключительно блочных протоколов. А так как NFS это не блочный протокол, то фичи блочных протоколов в нем быть не может “по определению”. Это так. Однако, NFS, как протокол поверх TCP/IP, конечно же имеет возможности реализации отказоустойчивости, путем использования множественных путей (как его имеет сам нижележащий TCP/IP), а также использования нескольких параллельных каналов доступа к данным, для расширения bandwidth.

Но тут есть некотрая тонкость. Проблема связана с тем, что NFS, для связи с данным датастором, с данным IP, и всеми его файлами, использует только одну TCP-сессию. А одну сессию, имеющую один IP-source и один IP-destination никак нельзя забалансировать по нескольким физическим портам Ethernet, даже с использованием etherchannel, формально работающем уровнем ниже.

Но можно (и нужно) выйти из положения хитрым трюком. Дело в том, что можно создать для destination несколько так называемых IP-алиасов, а также несколько портов VMkernel в качестве IP-source. Датастор, тем самым может быть доступен по нескольким равноправным IP-адресам. Если мы подключим датастор таким образом, у нас уже могут быть несколько различных IP-destination, через разные IP-source в VMkernel и, значит, заработает балансировка по IP-хэшу. Такой трафик, вышедший из нескольких IP-source в своих подсетях, и пришедший на сторадж в разные IP-алиасы, можно распределить по нескольким физическим eth-интерфейсам. Просто это присходит не “мистически-автоматически”, как в случае iSCSI MPIO, а путем ручной настройки этой балансировки, и дальнейшей ее самостоятельной работы.

Подробнее о этом методе рассказывается в TR-3802 Ethernet для систем хранения: Наилучшие методы (глава 4.6 IP-алиасы), и в TR-3749 Руководство по наилучшим способам использования систем NetApp с VMware vSphere (глава 3.3 Основы сети хранения с использованием Ethernet, глава 3.6 Сеть хранения с использованием Multiswitch Link Aggregation).

Дабы не раздувать один блогопост, чуть подробнее предлагаю углубиться в тему в отдельном посте далее, посвященном тому, как именно организована балансировка методом нескольких IP-алиасов на стороне стораджа, и нескольких портов VMkernel на стороне хост-сервера.

UPD: Если вы счастливый обладатель VMware в лицензии Enterprise Plus, то тогда вам доступен еше один вариант загрузки нескольких NFS-линков к стораджу - это режим Load-based Teaming для интерфейсов vnic. Об этом способе мы также поговорим чуть позднее в отдельном посте.

2. NFS нестабилен в работе и имеет проблемы с призводительностью.

“Мы видели это своими глазами, собрав сервер NFS на Linux” – добавляется явно или подразумеваемо. ?? это снова “и так, и не так”. Да, действительно, реализация NFS на Linux давно страдает серьезными проблемами, ее обычно приходится в продакшне твикать и патчить, только чтобы поправить некоторые наиболее вопиющие проблемы. В vanilla code она в продакшн малопригодна. Но это не значит, что любой NFS server также непригоден, только потому что он – NFS! Реализация NFS от NetApp зарекомендовала себя во множестве систем крайне высокого класса, ей по плечу задачи от небольших систем, до масштабов Yahoo!, Oracle, Siemens и Deutsche Telecom. NetApp имеет опыт разработки и эксплуатации NFS-серверов уже около 20 лет, в самых жестких условиях и требованиях по производительности и надежности.

??так: Не все реализации NFS “одинаково полезны”. ?? реализацией NFS в Linux многообразие их не исчерпывается. Не нужно интерполировать на NetApp неудачные реализации одной отдельно взятой подсистемы, в одной конкретной OS (или группе OS, использующих общих прародителей данного кода).

В следующей части я попробую более подробно остановится на методах multipathing для NFS, о которых выше в посте я вкратце уже упомянул.

VMware и использование NFS: часть 1

Как вы знаете, я убежденный сторонник того, что системы хранения NetApp – это лучший выбор для использования в среде серверной и десктопной вируализации. А для самой этой виртуализации – использование протокола NFS, который для систем NetApp, более чем родной, в свою очередь, лучший способ подключить дисковое хранилище. Со мной согласны уже 36% пользователей систем виртуализации (согласно отчету Forrester за май прошлого года), причем процент использования NFS растет, и уже превысил процент использования iSCSI (23%) на этих задачах.

Я уже не раз писал в этом блоге про различные аспекты использования NFS (посмотрите старые статьи по тегу NFS), и даже переводил на этут тему Best Practices (про Ethernet Storage вообще и про VMware в частности), однако все это были разрозненные публикации “к случаю”. Мне захотелось собрать основные темы вопроса в одном месте, и обсудить их, наконец, “раз и навсегда”, или пока тема не изменилась значительно.

Но для начала несколько вводных слов, для тех, только что подключился к блогу.

NFS (Network File System) – это протокол “сетевой файловой системы” разработанной компанией Sun в глубокой исторически-компьютерной древности, и предназначенный для доступа к данным в файлах по сети, в том числе для совместного доступа к ним от нескольких клиентов. NFS, вследствие своей сравнительной простоты реализации, стал очень популярным в UNIX-мире, где работу по NFS поддерживают практически любые OS. Несмотря на то, что сегодня “файловой системой” обычно принято называть нечто иное, за протоколом доступа к файлам по сети, NFS, исторически закрепилось название “файловая система”.  С момента своего изобретения, NFS прошел большой путь, и на сегодня достиг версии 4.2, обретя множество важных на сегодня возможностей, таких как использование не только UDP, как первоначально в исходной версии протокола, но и TCP (в v3), улучшенные технологии разграничения доступа и безопасности (v4), поддержка распределенных кластерных и объектных хранилищ (v4.1) и различные методы offload-а (v4.2).

К сожалению, за NFS водится два своеобразных недостатка. Во-первых, он так и не появился в OS семейства Windows (если не считать крайне проблемной реализации, вышедшей в составе продуктов MS Services for UNIX) и остался “чужим и непонятным” для win-админов. ?? второе, но более важное, не все его реализации “одинаково полезны”. Многие пользователи, познакомившиеся с NFS через имеющую кучу проблем с производительностью и стабильностью, широкораспространенной реализацией в Vanilla Linux, считают, что “весь NFS такой, глючный, тормозной, для продакшна не пригодный”. А это не так.

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

А теперь о достоинствах. Во-первых следует отметить сравнительную простоту использования NFS. Его использование не требует внедрения и освоения сложной, особенно для новичка, FC-инфраструктуры, непростых процессов настроек зонинга, или разбирательства с iSCSI. ??спользовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS это обычная монтируемая на хост сетевая “шара” с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает, например, резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы “автоматически” получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, оно становится доступно непосредственно администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2TB, даже с VMFS ранее 5, а это очень полезно, например, если вам приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. ??х всех можно поместить на один большой датастор, бэкапить, и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2TB(-512bytes) каждый.

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

Однако, какие у нас имеются минусы?

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). ??спользование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые, в случае блочного SAN, реализуются на стороне хоста, в случае NFS поддерживатся стораджем. Это всяческие блокировки, разграничение доступа, и так далее. Однако, практика показывает, что оверхед отражается на производительности крайне незначительно.

Большим плюсом использования NFS на стораджах NetApp является то, что выбор NFS там не диктует вам “жесткого выбора” для вашей инфраструктуры в целом. Если вам понадобится также и блочный протокол для RDM, или для крайне критичной даже к возможному 10-15% падению производительности виртуальной машины, вы можете использовать для нее iSCSI или даже FCP, все на том же сторадже, параллельно с NFS, и всеми его плюсами, для основного датастора.

В следующем посте этой серии мы перейдемь к разбирательству основных недопониманий и мифов, которые имеются вокруг использования NFS в VMware.

Рекомендуется также почитать по теме:

Сравнительное тестирование HDS AMS2100 и NetApp FAS2240-2

Нам пишут наши читатели:

Оригнал здесь, перепечатывается оттуда по согласию с автором: http://ua9uqb.livejournal.com/79872.html


Не так давно довелось мне протестировать две системы хранения данных, делюсь результатами. В тесте принимали участие системы начального уровня NetApp FAS2240 и Hitachi AMS2100.
Надо понимать, что системы эти сравнимы довольно условно, так как AMS - обычное, бедное по функционалу блочное хранилище, в отличии от сильно мозговитого, "всё-всё умеющего" NetApp-а. Конфигурации системы, методики тестирования, и прочие тюнинги, были согласованны со специалистами вендоров.

Немного подробностей по методике:
1. Тестирование проводилось программой IOMeter версии 2006.07.27 для Windows.

2. Подключение СХД Hitachi AMS2100 производится посредством FC4G, протокол FC
Cостав LUN и томов СХД
Raid10 8 x 450gb 15k 3.5’ Usable: 1.5Tb Lun: 700Gb
Raid6 8+2 450gb 15k 3.5’ Usable: 3.1Tb Lun: 700Gb

3. Подключение СХД NetApp FAS2240 производится посредством 10Ge, протокол iscsi
Состав LUN и томов СХД
RaidDP 9+2 x 600gb 10k 2.5’ Usable: 4.33Tb Lun: 700Gb

4. Тесты проводится в режиме файловой системы NTFS 4к, выравнивание партишина 64к;

5. Настройки программы IOMeter:
• Worker’s – 4
• Target – 16 (в каждом из Worker’s)
• Disk Size – 200000000 (100Gb)
• Ramp Up Time – 600 сек
• Run Time – 30 мин

6. Фиксация результатов каждого теста для IOMeter длиться 30 минут начиная с 10-й и заканчивая 40-й минутой теста;

7. Профили нагрузок(название профилей условное), используемые для тестирования IOMeter следующие: 
Нагрузка характерная для приложений ORACLE 
• размер блока 8КБ;
• соотношение количества операций чтения/запись 30/70;
• характер нагрузки – 100% случайный доступ;

Нагрузка характерная для VMware:
• размер блока 4КБ;
• соотношение количества операций чтения/запись 40/60;
• характер нагрузки – 45% линейный и 55% случайный доступ;

Нагрузка характерная для операций Backup:
• размер блока 64КБ;
• 100% последовательное чтение;

??тог:

Табличка довольно прозрачная, поэтому никаких выводов делать не буду.
NetApp FAS2240(в центре, где куча вертикальных планочек, и жёлтая наклейка сверху):

 

Hitachi AMS2100

PS. Дополнительно проводилось тестирование программой IOZone, порядок цифр примерно тот же, если будут интересующиеся, выложу результаты.

PPS. Пост навеян коментом френдессы [info]balorus к посту про сервер Sun T4-4 :-)

PPPS. Мой выбор был бы NetApp, если бы Хитача в те же деньги не уложила сильно больше шпинделей. А так же не ещё один сильно политический нюанс, который очень сложно перебить даже теми волшебными, и крайне необходимыми нам штуками, которые NetApp умеет делать очень хорошо, а AMS не умеет в принципе.

Установка NetApp VASA Provider

Для начала несколько слов о том, что такое собственно этот VASA Provider.

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

Continue reading ‘Установка NetApp VASA Provider’ »