В продолжение темы об оптимизации хоста с VMware ESXi, рассмотрим как поступать со Swap'ом в инфраструктуре живущей на СХД NetApp FAS. Хотя эта статья должна быть полезна и не только владельцам систем NetApp FAS.

Одна из важнейших возможностей виртуализации заключается в возможности более эффективно утилизировать серверное оборудование, что подразумевает Overcommit ресурсов. Если мы говорим об ОЗУ, это означает, что мы можем настроить каждой виртуальной машине больше памяти, чем есть на сервере на самом деле. А дальше мы полагаемся на ESXi, чтобы тот разрулил борьбу за ресурсы — забрал (такой процесс часто называют reclamation) не нужную память одной виртуальной машины и отдал той, которая в ней действительно нуждается. В тот момент когда не хватает памяти, начинается процесс свапинга памяти.

Начнём с того, что есть два типа свапинга, которые могут происходить на ESXi хосте. Их очень часто путают, поэтому давайте условно будем называть их Тип 1 и Тип 2.


Расположение данных VMware ESXi по умолчанию

В продолжение темы об оптимизации хоста для взаимодействия с СХД NetApp FAS, эта статья будет посвещена оптимизации производительности VMWare ESXi, предыдущие статьи были посвящены тюнингу ОС Linux и Windows в среде SAN. Компания NetApp давно тесно сотрудничает с VMware, подтверждением тому может стать тот факт, что нашумевшая технология vVOL была реализована одной из первых ещё в релизе Clustered Data ONTAP 8.2.1 (Август 2014), в то время как vSphere 6.0 ещё даже не выпущен. В связи с чем системы хранения NetApp FAS крайне популярны в этом окружении. Часть про Disk Alignment будет полезна не только владельцам NetApp.

Настройки VMWare ESXi можно разделить на следующие части:

• Оптимизация гипервизора
• Оптимизация гостевой ОС (GOS)
• Оптимальные настройки SAN (FC/FCoE и iSCSI)
• Настройки NAS (NFS)
• Проверка совместимости оборудования, прошивок и ПО

Для поиска узкого места обычно выполняют методику последовательного исключения. Предлагаю перво-наперво начать с СХД. А дальше двигаться СХД -> Сеть (Ethernet / FC) -> Хост ( Windows / Linux / VMware ESXi 5.Х и ESXi 6.X ) -> Приложение.

В этом посте я хотелбы рассмотреть подход к резервному копирования данных на СХД NetApp серии FAS.


Архитектура резервного копирования

WAFL

И начну я издали — со снепшотов. Технология снепшотов впервые была изобретена (и запатентирована) в 1993 году компанией NetApp, а само слово Snapshot™ является её торговой маркой. Технология снепшотирования логически проистекала из механизмов работы файловой структуры WAFL. Почему WAFL не файловая система смотрите здесь. Дело в том, что WAFL всегда пишет новые данные «в новое место» и просто переставляет указатель на содержимое новых данных в новое место, а старые данные не удаляются, эти блоки данных, на которые нет указателей, считаются высвобожденными для новых записей. Благодаря этой особенности записи, «всегда в новое место», механизм снепшотирования был легко интегрирован в WAFL, из-за чего такие снепшоты называют Redirect on Write (RoW). Подробнее про WAFL.

Совершенно неожиданно для меня вышла стабильная версия мультиплатформенного гнератора синтетической нагрузки IOMeter2 v1.1.0. IOMeter часто применяют для тестов дисковой подсистемы, хотя он также может генерировать нагрузку на сеть. Интерфейс совершенно не притерпел изменений. В предыдущей статье я тестировал СХД NetApp FAS подключённый по FC4 к хосту на стабильной версии IOMeter2 2008-06-22-rc2.

При нагрузочном тестировании не забывайте, что нужно оптимально настроить цепочку:
СХД -> Сеть (Ethernet / FC) -> Хост ( Windows / Linux / VMware ESXi ) -> Приложение.
Чтобы получить наилучшие результаты как в синтетически тестах, так и на реальных данных. Одного сервера может оказаться не достаточно чтобы нагрузить СХД.

Из важных нововведений:

• Поддержка Windows UAC.
• Пофикшен Windows Disk detection, позволяющий работать с новыми дисками. Диск с таблицей разделов GPT в качестве блочного устройства по-прежнему не поддерживается.
• Data randomization — появилось три варианта, сильно отличающихся генерируемым патерном случайности.
• К сожалению не все старые версии конфигов совместимы с новой версией IOMeter2, привожу патерны нагрузки для новой версии чуть ниже.

Для Outstanding I/O максимальное значение может быть 256, тогда как 128 означает высокую нагрузку схожую с высоконагруженными БД.

В продолжении темы по оптимизации хоста. В предыдущей статье я писал об оптимизации Windows и SAN сети, в этой статье я хотел бы рассмотреть тему оптимизации RedHat/Oracle Linux (с виртуализацией и без) с использованием СХД NetApp FAS в среде SAN.

Для поиска и устранения узких мест в такой инфраструктуре, нужно опредилиться с компонентами инфраструктуры, среди которых их стоит искать. Разделим инфраструктуру на следующие компоненты:

• Настройки хоста c SAN (FC/FCoE)
• Настройки Ethernet сети на хосте для IP SAN ( iSCSI ).
• Собственно сам хост с ОС
• Приложениями на Хосте
• Проверка совместимости драйверов и версий ПО

В этой статье я хотел бы рассмотреть тему оптимизации Windows Server (с виртуализацией и без) с использованием СХД NetApp FAS в среде SAN.

Для поиска и устранения узких мест в такой инфраструктуре, нужно опредилиться с компонентами инфраструктуры, среди которых их стоит искать. Разделим инфраструктуру на следующие компоненты:

• Настройки хоста c SAN (FC/FCoE)
• Настройки Ethernet сети на хосте для IP SAN ( iSCSI ).
• Собственно сам хост с ОС
• Приложения на Хосте
• Проверка совместимости драйверов и версий ПО

В этой статье я сфокусируюсь на оптимизации производительности систем NetApp FAS.

Объектами оптимизации с точки зрения СХД могут быть настройки:

• SAN в СХД
• Ethernet в СХД
• NAS в СХД
• Дисковой подсистемы на Back-End СХД
• Дисковой подсистемы на Front-End СХД
• Проверка совместимости прошивок
• Ускорители

Для поиска узкого места обычно выполняют методику последовательного исключения. Предлагаю перво-наперво начать с СХД. А дальше двигаться СХД -> Сеть (Ethernet / FC) -> Хост ( Windows / Linux / VMware ESXi 5.Х и ESXi 6.X ) -> Приложение.

В продолжение предыдущей статьи "Ethernet & FC", хотел бы дать конкретные рекомендации по оптимизации Ethernet сети для работы с СХД NetApp FAS. Хотя, полагаю, многие вещи описанные здесь могут быть полезны и для других решений.

SnapManager — это набор утилит компании NetApp позволяющих автоматизировать процессы снятия так называемых Application-Consistent Backup (ACB) и Crash-Consistent Snapshots (CCS) без остановки приложений, средствами СХД NetApp FAS серии, их архивации, резервного копирования, тестирования копий и архивов, клонирования, примапливания склонированных данных к другим хостам, восстановления и др. функциями через GUI интерфейс одним только лишь оператором приложения без привлечения специалистов по серверам, сети и СХД.


SnapManager for Oracle on Windows, Cloning Operation

Зачем вообще бэкапировать данные при помощи снапшотов и тем более средствами СХД? Дело в том, что большинство современных способов бэкапирования информации подразумевают длительность процесса, ресурсоёмкость: нагрузка на хост, загрузка каналов, занимание пространства и как следствие к деградации сервисов. Тоже касается и клонирования больших объемов информации для Dev/Test подразделений, увеличивая «временной разрыв» между актуальными данными и резервируемыми, это повышает вероятность того, что бэкап может оказаться «не восстановим». С применением «аппаратных» снапшотов компании NetApp, не влияющих на производительность и занимающий не положенные 100% резервной копии, а только лишь «разницу» (своего рода инкрементального бэкапа или лучше сказать обратного инкрементального бэкапа, на снятие и сборку которого не нужно тратить время), а также возможность передачи данных для резервирования и архивирования в виде снапшотов, позволяя более элегантно решать современные высокие требования бизнеса для подобных задач, уменьшая время передачи информации и нагрузку на хосты.

Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.


* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.

Для небольших компаний нередко применение всего двух-четырех серверов с виртуализацией, два Ethernet свитча порой даже с возможностью стекирования и Multi-chassis EtherChannel плюс СХД младшей серии — это вполне стандартная конфигурация инфраструктуры среднего бизнеса.
Таким предприятиям очень важно максимально задействовать все доступные технологии, чтобы максимально утилизировать своё оборудование и в этой статье пойдёт речь как этого добиться.

В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента.

На СХД младшей серии NetApp FAS2240/FAS2220 на борту каждого контроллера помимо прочего присутствует 4х 1Gb порта.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC как у свитчей компании Cisco серии Nexus, в таком случае вместо интерлинков просто будет использован стек свичей. Да и вообще сервера и свитчи в такой схеме могут быть любого производителя. А если совсем всё туго с бюджетом, то можно использовать прямое включение в сервера, так если у сервера 2 порта на борту, можно будет подключить 4-ре сервера, а когда нужно будет добавить 5-й сервер, тут уж прийдётся покупать свитчи.


Схема подключения FlexPod Express.

Многие слышали, что на западе владельцы ЦОД постоянно обеспокоены количеством потребляемой энергии и то, что их содержание обходится очень дорого. Одна из самых прожорливых компонент ЦОД это СХД, связано это с тем что последние используют большое количество механических жестких дисков. Многие также слышали что электроэнергия «за бугром» на много дороже. А как обстоят дела у нас?

Всем кто вовлечён в процесс эксплуатации СХД NetApp, продажи, пресейла, конечным заказчикам, инженерам, могут быть полезны следующие мобильные приложения.

NetApp Document Search

Android
Предоставляет доступ в публичную библиотеку NetApp которая содержит истории заказчиков, аналитические, технические и исследовательские документы и документы по поддержке, а также видео. Приложение доступно широкой общественности и не требует наличия регистрационных данных.
Будет интерестно для конечных пользователей, интеграторов и представителей дистрибютеров.

Во время тестирования СХД специалисты часто встречаются с проблемами в производительности в связи с нюансами настройки всего комплекса. Для нагрузочного тестирования СХД не достаточно только лишь запустить симулятор нагрузки, необходимо настроить систему хранения, сеть и хост. Основная масса настроек, как правило, выполняется именно на хосте.

Целью данной статьи помощь системным администраторам и системным интеграторам в понимании настроек и нюансов при тестировании СХД NetApp. Хочу также отметить, что в этой статье не было задачи в получении максимально возможной производительности контроллеров NetApp FAS 2240, так как на момент тестирования демо оборудования не было достаточного количества дисков (144 максимум) для СХД, а также в наличии был только один сервер. Т.е. максимальная производительность здесь рассматривается в контексте конкретной конфигурации демо стенда, другими словами при большем количестве дисков, серверов и подключений по сети возможно получить результаты ещё лучше с теми же контроллерами 2240. Хотя все графики с результатами производительности взяты с реальных конфигураций конечных заказчиков, использующих в тестах контроллеры 2240, в некоторых тестах использовались четыре SSD 100GB MLC диска.

Ниже приведено комплексное описание нагрузочного тестирования СХД: настройки симулятора нагрузки IOMeter, методика настройка хоста и СХД NetApp FAS, снятие статистики нагрузки, а также интерпретация полученных результатов. На примере существующего демо стенда будет рассмотрены методы настройки всех его компонент, а также других возможных вариантов конфигураций с использованием NetApp FAS.

Уважаемые друзья!

Компания Мегатрейд предлагает всем желающим участвовать в Web-Ex презентации на тему Интеграция СХД NetApp FAS и решения для резервного копирования данных от SyncSort*.
Интересна ли вам данная тема? Есть ли у вас вопросы в этой области? Возможно есть, чем поделиться? Если ответ – Да!, проходите на регистрацию. Заявки принимаются до 17 января 2014 года. Время начала презентации 20 января 2014 в 11:00 UTC+0 (GMT), длительность презентации 2 часа.

Для полноты понимания или для тех, кто еще не слышал о совместном «наборчике» от законодателей мод в мире IT – предыстория:

В относительно недалеком 2010 году компании Cisco, NetApp & VMWare выпустили CVD и NVD -валидированую архитектуру под названием FlexPod. В состав решения входят СХД NetApp FAS, Сервера Cisco UCS, фабрика Cisco UCS Fabric Interconnect, конвергентный коммутатор Cisco Nexus 5548UP и гипервизор VMWare (а в последствии и Hyper-V). Решение стало довольно популярным в виду актуальных трендов «частного облака», консолидации и виртуализации ИТ систем в целом.

Уважаемые друзья!

Компания Мегатрейд предлагает всем желающим участвовать в Web-Ex презентации на тему NetApp — Эффективное хранение данных.
Интересна ли вам данная тема? Есть ли у вас вопросы в этой области? Возможно есть, чем поделиться? В конце концов вы просто хотите выиграть ценные призы за самые интересные вопросы? Если ответ – Да!, проходите на регистрацию. Заявки принимаются до 23 июня 2013 года.

Как-то незаметно на просторах IT прошла новость о покупке компанией Cisco копании Cloupia за 125 миллионов долларов США. Cisco увидела дополнение своего портфолио решений для Датацентров предоставляющих облачные услуги, софтом от Cloupia.Напомню также что Cloupia это первый оркестратор, валидированный обоими: Cisco и NetApp, для управления FlexPod архитектурой.Что такое FlexPod, можно ознакомится в соответствующей статье на хабре. Для пущей наглядности картинок будет много.

CUIC

CUIC — это оркестратор для инфраструктуры ЦОД, способный объединить под своим управлением как физическое оборудование в ЦОД, так и виртуализированные среды. С его помощью можно осуществлять оркестрацию из «одной точки» входа. Таким образом это средство способное предоставлять услуги как: IaaS и PaaS.
Примеры такого оборудования:

• Сетевые маршрутизаторы и коммутаторы: Cisco Nexus 7000, 5000, 1000v.
• Вычислительные системы: Cisco UCS Fabric Interconnect.
• Различные системы хранения данных, в том числе и NetApp.
• Виртуализация: VMware, Microsoft, Citrix.

Возможности CUIC

Возможность «управления из одного места» далеко не всё, что умеет этот оркестратор.

Многие из вас, возможно, слышали это слово из IT новостей. Что же это значит и почему это должно быть интересно? Постараюсь ответить на оба эти вопроса.
FlexPod это архитектура для ЦОД.

Архитектура

FlexPod – это апробированная архитектура, которая в рамках инфраструктуры коллективного пользования предоставляет необходимые средства для работы в сети, вычислительные средства и средства хранения данных, а также поддерживает работу множества приложений и рабочих заданий, что помогает предельно упростить переход к «облачным вычислениям».
Существует около 60 превалидированных решений и это число будет только увеличиваться.
Архитектура включает в себя следующие компоненты:

В продолжение статьи Что такое FlexPod?. Если в кратце, то FlexPod — набор конфигураций серверного и сетевого оборудования и программного обеспечения для ЦОД, предлагаемый компаниями Cisco и NetApp, сформированный на основе серверов Cisco UCS, коммутаторов Cisco Nexus, систем хранения данных NetApp FAS.

24 января 2013 компании NetApp и Cisco объявили о расширении сотрудничества.

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

• Более глубокая интеграция архитектуры FlexPod: Cisco и NetApp продолжают интеграцию своих продуктов Cisco UCS и NetApp FAS и открытых экосистем менеджмента FlexPod.
  Решение FlexPod предоставит возможность управлять до 10000 серверами предоставляя организациям объединять несколько стоек FlexPod и использовать Multihop FCoE. Эти решения разработаны специально для Сервис-Провайдеров и предприятий с филиальной структурой, предоставляя возможность масштабирования инфраструктуры с предсказываемой производительностью и тех-поддержкой.
  FlexPod продолжает лидировать в интеграции с утилитам менеджмента инфраструктуры и будет поддерживать Cisco UCS Manager 2.1. Cisco недавно поглотила компанию Cloupia последовательно продолжая и развивая стратегию унифицированной конвергентной инфраструктуры. В дополнение поддерживается Cisco Intelligent Automation для Cloud (Cisco IAC) позволяя управлять облачными решениями для заказчиков FlexPod. Более глубокая интеграция по всему FlexPod на уровне платформы, в отличае от компонентного уровня позволяя легко оркестировать FlexPod средствами партнёрских решений, в том числе Microsoft System Center и Citrix CloudPlatform powered by Apache CloudStack.