Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Vsphere | about NetApp

Posts tagged ‘vsphere’

NetApp VSC 5.0 for VMware vSphere Web Client Now Available

Что называется, новость из серии “срочно в номер”.
?так, вышел в релиз долгожданный Virtual Storage Console 5.0, или VSC, работающий с vSphere Web Client, после выхода vSphere 5.5 - основного средства администрирования vSphere.
Как вы, наверняка, знаете, вот уже пару лет, как VMware объявила, что она отказывается в новых выпусках vSphere от управления многим привычным, так называемым “толстым”, клиентом, устанавливаемым на компьютер админа и работающим локально, а переходит полностью на web-клиент, “тонкий”, работающий в браузере.

Казалось бы, с одной стороны, все хорошо, веб-интерфейс, браузер, все дела. Стильно, модно, молодежно. Проблемы, однако, начались у многочисленных разработчиков дополнений и плагинов, ранее работавших через “толстого” клиента. Всем им пришлось переписываться, причем так как, кроме внешнего изменения клиента, поменялось многое и в общем представлении данных в клиенте, то переход затянулся довольно надолго. Затянулся он и для NetApp. Основной, и очень важный инструмент для работы с хранилищем NetApp в среде VMware, плагин VSC версии 4, работал только с толстым клиентом и это, безусловно, мешало многим пользователям NetApp начать переход на веб-клиент vSphere. С одной стороны - вот он, в версии 5.5 уже объявлен основным, более того, некоторые функциональные возможности управления уже есть только в нем, так как “толстый” клиент официально год как deprecated, а использовать веб-клиент без VSC, при наличии NetApp - довольно бессмысленно.

? вот, наконец, релиз VSC 5, совместимого с веб-клиентом. Благословясь, можно начинать полный переход на веб-клиента vSphere, сперва в тестовых системах, если они у вас есть, например на симуляторе и в лабе.

Размер VSC 5.0 для скачивания остался примерно тем же, 268 мегабайт, однако вместе с VSC как таковым (он теперь существует только под x64) выпущен также и VASA Provider в виде OVA-модуля, удобного к развертыванию, этот вариант больше. Качайте то, чем в реальности пользуетесь.

?з новинок - конечно же полная поддержка Clustered ONTAP. Также для cDOT выпущен и VASA Provider, позволяющий управлять ОЧЕНЬ большими инфраструктурами. Я немного писал про него тут.

Также хочу отметить, что если вы используете vSphere 5.5, но при этом НЕ переходите по каким-то причинам на web-клиент (например используете также какие-то старые, до-5.5 фермы в своей инфраструктуре), то тогда выш выбор - VSC 4.2.1 полностью совместимый с vSphere 5.5, с одной стороны, и работающий в “толстом” клиенте, обычным образом, с другой. Качается там же.
Но помните, что 5.5 - последняя версия vSphere, поддерживающая “толстый” клиент управления.

VSC 5.0 goes public beta

?так, долгожданный 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 это все же еще не то, что можно ставить на продакшн, по крайней мере как единственный инструмент управления. Но посмотреть уже можно.

VSC для VMware Web Client UI

Как вы уже, наверняка, знаете, после выхода версии ESXi 5.1, VMware объявила, что это будет последняя версия, поддерживающая “толстый клиент” vSphere. В дальнейшем поддержка традиционного, “толстого” клиента будет прекращена, и вся работа с vSphere будет происходить через так называемый Web Client UI, работающий в веббраузере.

Все бы хорошо, но есть существенная сложность – многочисленные, написанные вендорами плагины для VCenter, в частности NetApp Virtual Storage Console – VSC. Подобные плагины, для работы с системой хранения из интерфейса клиента VCenter, написали под свои стораджи почти все крупные вендоры. Но все они работают с “толстым клиентом”. По этой причине для тех, кто использует соответствующие стораджи, и управляет ими через пдобные плагины, наступают тревожные времена. Успеют ли соответствующие вендоры выкатить новые версии своих плагинов до того, как наступит время отказаться от “толстого клиента”?

NetApp пока неофициально объявил, что в среде Web Client UI будет работать новая версия VSC 5.0, она запланирована к выходу в конце этого года. Это будет существенно переработанная версия, что связано с тем, что изменяется сама логика работы и интеграции подобных плагинов. Так, например, ресурсы стораджа (контроллеры и VServers в Cluster-mode) будут интегрированы в стадартный inventory VCenter. Также, наконец, закончится процесс интеграции модулей VSC в “единое операционное пространство”.

Как вы, возможно, помните, нынешняя ситуация, с отдельными модулями Monitoring & Host Configuration, Provisioning & Cloning, Optimization & Migration, и Backup & Recovery, это отголосок того, что раньше VSC был надстройкой над несколькими различными продуктами, такими как SnapManager for Virtual Infrastructure (SMVI), Rapid Cloning Utility, и так далее, которые существовали отдельно, сами по себе, как отдельные продукты. Потом поверх них надстроили интеграционный плагин VSC, некую общую консоль, но продукты, тем не менее, еще долго оставались самостоятельными, даже когда они впоследствии вошли в состав VSC как его компоненты. Однако логически это разделение функциональностей по модулям еще сохранялось (и сохраняется сейчас), когда никакой физической разделенности на фактические модули за этим уже нет. Вот, наконец, в VSC 5.0 нам пообещали, что от этого намерены избавиться.

Кстати, кто в курсе темы, прокомментируйте, а у EMC уже есть плагин для VNX под VCenter Web Client UI?

ExpressPod – “сделай сам”

Если вы заинтересовались упомянутым ранее продуктом ExpressPod, это недавно появившаяся у NetApp “коробка”, готовый “продукт”, состоящий из стораджа FAS2240/2220 серверов Cisco UCS C-series (1-юнитовых 19”) и коммутаторов Cisco Nexus 3000 (48x 100/1000 Ethernet + 4x 10G, под NX-OS), ориентированный, прежде всего, на задачи построения “платформы виртуализации”, то в библиотеке NetApp появился новый документ:

ExpressPod Infrastructure Solution Implementation Guide
VMware vSphere on ExpressPod

Michael Zimmerman, David Klem, Chris Reno, and Michael Ansel, NetApp
October 2012 | TR-4107

http://media.netapp.com/documents/tr-4107-VMware-vSphere-ExpressPod.pdf

 

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

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: часть 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 в одной подсети’ »

О использовании EtherСhannel в vSphere

Несмотря на то, что основная тема блога – системы хранения, прежде всего системы хранения NetApp, поневоле приходится затрагивать интересные смежные темы. Раз уж мы заговорили тут про NFS, стоит затронуть тему использования LACP при организации EtherChannel, так как, как я заметил, понимание этой темы у многих все еще довольно зыбкое.

Поэтому, в очередных переводах в этом блоге – перевод поста в интересном блоге Wahl Network

Демистификация LACP и Static EtherChannel в vSphere

May 9, 2012

Удивительно часто я слышу о людях, которые воспринимают LACP как некую волшебную палочку, которой достаточно махнуть, и все чудесным образом становится лучше, а трафик волшебным образом распределяется по множеству линков. Я думаю, что это происходит от непонимания базового устройства того, как работает EtherChannel, так как я слышал множество ошибочных утверждений и FUD вокруг этого. Этот пост является попыткой описать то, что же за штука, этот LACP, почему он не работает на обычных, native vSphere switches, и почему он, на деле, имеет совсем небольшое количество преимуществ, в сравнении со static EtherChannel.

?так, что такое LACP?

LACP, иначе известный как IEEE 802.1ax Link Aggregation Control Protocol, это простой способ динамически строить EtherChannel. Для этого "активная" сторона группы LACP посылает специальный фрейм, оповещающий о возможностях и желаемых формах EtherChannel. Возможно существование, и чаще всего так и бывает, когда обе стороны являются "активными" (может быть и пассивная сторона). Также следует отметить, что LACP поддерживает только full duplex линки (в настоящий момент, в мире гигабитных, и более, линков, которые всегда full duplex, это уже не является значимым ограничением). Как только обмен фреймам произведен, и порты на обоих сторонах согласовали поддержку требований, LACP создает EtherChannel.

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

LACP отсутствует в Native vSphere Switches

Ситуация проста, нативные коммутаторы vSphere не отвечают на фреймы LACP. Они не слушают и не передают соответствующие кадры. Если вы настроили LACP на внешнем коммутаторе, он не получит отклика на запросы LACP от хоста vSphere, и, следовательно, EtherChannel не будет создан.

Если вы хотите создать EtherChannel с участием хоста vSphere, вы должны создать Static EtherChannel. Когда порт установлен в Static, он не участвует в процессах объявления или распознавания LACP – канал EtherChannel немедленно создается физическим коммутатором.

Как работает распределение нагрузки (Load Distribution)?

Главная мысль:
Как Static так и Dynamic (LACP) EtherChannel используют одни и те же методы распределения нагрузки (load distribution).

Я специально выделил это курсивом и жирным шрифтом. Да, это правда. ? Static, и LACP используют одни и те же техники балансировки нагрузки для распределения трафика по линкам. Если кто-то утверждает иное, то можете поспорить с ним на деньги, можете хорошо выиграть.

Но Static EtherChannel требует IP Hash, а LACP - нет, не так ли?

А сейчас переходим в темную часть. Ответ на заданный в заголовке вопрос: "Это не так", но вот почему это не так?

IP Hash это требование native vSphere switch. Он не поддерживает никакие другие методы load distribution.

clip_image001

Скриншот выше взять из vSphere Networking guide

А это уведомление из vSphere:

clip_image002

Отметьте, что если я хочу использовать EtherChannel, я выбираю IP Hash в качестве метода балансировки, и появляется данный бокс с сообщением.

Внимание: Термин IP Hash эквивалентен политике load distribution policy вида src-dst-ip на коммутаторе Cisco.

Static EtherChannel в других случаях может использовать любые из доступных политик распределения нагрузки. Но когда порты работают с хостом vSphere, мы вынуждены использовать только IP Hash, так как vSphere ничего другого не умеет.

Если вы хотите использовать LACP с vSphere, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v). Нет других способов задействовать LACP с vSphere на момент написания этого поста. ?, так как 1000V это (почти) полнофункциональный коммутатор Cisco, в отличие от native vSphere switch, вы можете использовать любые политики load distribution – вы не ограничены только IP Hash (src-dst-ip)

Преимущества LACP перед Static

LACP имеет несколько "карт в рукаве", но это не относится к методам распределения трафика по каналам EtherСhannel.

Hot-Standby Ports

Если вы добавите больше поддерживаемого числа портов в LACP port channel, есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его.

Однако, типичное число поддержваемых портов в LACP равно 8, так что для системы vSphere это не та возможность, о коорой стоит беспокоиться. Сомнительно, что у вас сделан 8-канальный EtherChannels к одному хосту vSphere.

Failover

Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Проверка конфигурации

EtherChannel с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено нормально. Static EtherСhannel не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

Выводы

Я не хочу сказать, что LACP (или Nexus 1000V) это плохо. LACP - это очень полезный и популярный протокол, активно используемый. Проблема, побудившая меня написать этот пост в том, что я вижу людей, которые считают что с использованием LACP они получат лучшую балансировку трафика, или же что-то еще, что он совершенно точно не делает. Так что не спешите закупать Cisco 1000V для вашей системы vSphere только оттого, что вы хотите использовать LACP, пока вы не будете иметь ясного плана того, что, на самом деле, вы хотите получить в результате.

?сточник:
http://wahlnetwork.com/2012/05/09/demystifying-lacp-vs-static-etherchannel-for-vsphere/

Михаил Михеев - Администрирование VMware vSphere 4.1

Уважаемые посетители, кто приходят с поисковиков в поисках книги “Администрирование VMware vSphere 4.1” Михаила Михеева.
Я понимаю, что вы ищете. Нет. Здесь негде скачать эту книгу. ? не будет никогда.
Пойдите и потратьте 400 рублей на ее покупку.
Это вам вполне по силам и по карману.
Во-первых это хорошая книга, лучшая из написанных на эту тему на русском языке.
Во-вторых - иметь таку книгу в руках “в бумаге” это удобнее в работе, чем слепые и кривые PDF-сканы.
В третьих, наконец, купив книгу вы стимлируете издательство и автора издать следующую книгу этой тематики.
Вот вам все возможные места, где ее можно купить в интернете:

Озон
Альянс-книга
Spinter
Библио-глобус
Biblio-globus.us

Обратите внимание, что вышло второе, исправленное и дополненное издание, которое внешне, на магазинной полке, отличается от первого цветом обложки. Первое издание имело обложку в зеленых тонах, второе - в синих.

Mихаил Михеев Администрирование VMware vSphere 4.1

NetApp and VMware vSphere Best practices на русском!

“Еще одно, последнее сказанье, и летопись окончена моя”.

Мы это сделали. Да! На сайте компании-дистрибутора Netwell опубликован мой перевод 97-страничного “Руководства по наилучшим методам использования систем NetApp с VMware vSphere”, перевод TR-3749, в версии 2.1, августа этого года обновлено до версии 3.0. Точное название файла смотрите на сайте Netwell!

Скачать PDF
Читать и ссылаться на html

Увы, на этом активные переводы мои пока завершены. Бюджета на них больше нет, а фидбэк от читателей, как ни печально, минимальный.
Кстати, если вы пользуетесь моими переводами с сайте Netwell, и считаете их полезными, а также были бы рады их продолжению, то не ленитесь черкнуть по этому поводу электронное письмо по адресу info@netwell.ru. В том числе с благодарностью будут приняты и идеи того, какие бы документы, на какую тему из уже созданных и выложенных на английском в Technical Library у NetApp, вы бы хотели иметь на русском языке, в переводе.

Хочу выразить благодарность моим папе, маме, собаке автору и ведущему блога vm4.ru, автору бесценной по количеству полезной информации книжки “Администрирование VMware vSphere”, Михаилу Михееву, за терпение и отзывчивость, а также за ряд важных комментариев и консультации в ходе перевода, хотя, увы, не все из них и попали в окончательный текст

Чтобы два раза не вставать, пользуясь случаем, хочу сообщить, что в период новогодних каникул “рашэн кристмас” новых постов не будет (все равно меня читают, как я знаю, только в рабочее время и в рабочие дни), вернемся к регулярности во второй половине января, не переключайте ваши браузеры.

UPD: Обратите внимание, что несмотя на то, что документ в целом посвящен практике использования систем NetApp для хранения данных VMware, тем не менее в документе есть много полезной информации, если ваша система хранения под VMware (пока еще;) не NetApp.
Так, например, подробно рассматриваются вопросы организации отказоустойчивой избыточной сетевой инфраструктуры Ethernet, для подключения с помощью iSCSI или NFS, а также ряд дугих полезных и важных вопросов. Так что рекомендую просмотреть этот документ, даже если вы только и просто интересуетесь, и используете какие-то иные системы хранения.

20/0.121

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.