Pull to refresh
0

Пример практического проекта с использованием NetApp FAS2040A

Reading time 8 min
Views 12K


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

Вводная информация по проекту была такая.
Организация рассматривает возможность создания большого внутреннего «частного облака», на котором планируется оказывать внутренние IT-услуги в разветвленной организационной структуре компании, аренды приложений, SaaS, развертывания системы виртуализации десктопов (на базе VMware View и/или Citrix Xen Desktop) и так далее. Базовой системой для организации «облака» планируется решение VMware. Специально, для невнимательно читающих, особо выделю, что речь идет про внутреннее частное «облако», со своими, специфическими задачами и требованиями, НЕ про услуги веб-хостинга.


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

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

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





Краткие технические характеристики системы хранения FAS2040A:
Мультипроткольная,«unified storage» система хранения. Возможные протоколы работы с данными: FC, iSCSI, CIFS (SMB, SMB2.0), NFS v3, v4.
Два контроллера в High Availability кластере.
На каждом контроллере 4 порта Gigabit Ethernet, 2 порта FC 4Gb/s, каждый контроллер имеет 4GB кэш-памяти.
Максимальное количество используемых дисков — 136 (до 136TB общей емкости хранения).

Несмотря на то, что, конструктивно, NetApp FAS2040 и позволяет установить непосредственно в корпус контроллера системы хранения 12 дисков SAS или SATA, и сэкономить в небольшой конфигурации на дисковой полке, был выбран вариант без дисков в корпусе, и с подключением внешней дисковой полки DS4243 на 24 диска, в который установлены диски SAS 300GB 15K.



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

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

Как я уже рассказывал ранее, стоимость готовой системы хранения NetApp складывается из двух основных частей: из стоимости «железной» части, и стоимости «софта», то есть лицензий на те или иные опции, протоколы и возможности. Покупая систему хранения вы выбираете набор возможностей из имеющегося «меню», или же покупаете готовый «пак» (часто такой «комплексный обед» обходится дешевле, чем «заказ по меню»). По этой причине цена на две разных готовых системы может сильно отличаться даже для сходного набора «железа» (например количества дисков). Это, кстати, одна из главных причин, почему, говоря о «абстрактных» системах хранения NetApp я не называю, да и не могу назвать конкретных цен.
В данном случае при конфигурировании был заказан так называемый Virtualization Pack*, в который входит набор лицензий на опции и протоколы доступа, соответствующий потребностям работы системы хранения в среде виртуализации, с VMware vSphere, MS Hyper-V, Citrix Xen, и других.

В этот «комплексный обед» входят протоколы iSCSI, NFS и FC, а также множество дополнительных полезных лицензий и программных продуктов, например SnapManager for Virtual Infrastructure, который позволяет делать консистентные снэпшоты виртуальных машин средствами системы хранения, при этом лишенные недостатков снэпшотов VMware, а также неограниченная лицензия на SnapDrive для Windows и UNIX/Linux, инструмента, позволяющего управлять созданием снэпшотов и подключать RDM внутри виртуальных машин, и кроме этого много других возможностей, таких как дедупликация, thin provisioning, синхронная и асинхронная репликация на другой сторадж NetApp, резервное копирование снэпшотами, и другие возможности.

Мы не будем использовать FC, это сознательное решение ухода от FC в пользу конвергентной Ethernet-сети, но протокол на сторадже у нас будет, и, если такая потребность у компании вдруг возникнет, они легко и без дополнительных затрат смогут подключить к этому решению и сервера по протоколу FC (на системе хранения имеется 4 порта FC, то есть пару серверов можно подключить избыточным подключением даже без использования FC-коммутаторов, «прямым проводом», а больше, скорее всего, и не пригодится), или же, например, ленточную библиотеку для резервных копий.

В серверной части решения был сделан выбор в пользу пока не самого известного в России серверного производителя — Cisco, и ее нового, для компании, продукта — серверов семейства UCS — Unified Computer System. Семейство UCS состоит из двух линеек: UCS B-class — blade-систем, и UCS C-class — «обычных», стоечных, «рэковых» серверов, в типовой 19" шкаф. В данном проекте мы выбрали сервера Cisco UCS C250M2.



Причин этому выбору также было несколько. Во-первых, в дальнейшем планируется использовать (в «большом» проекте) сервера UCS семейства B (blade), в этом случае уже имеющиеся сервера Cisco UCS C удобно управляются «большим» инструментарием администрирования UCS B.
Во-вторых, серверные решения Cisco ясно нацелены на сегмент серверной виртуализации, с соответствующими аппаратными решениями в них, например, уже упомянутый Cisco UCS C250M2, отличается весьма большим доступным серверу объемом памяти, а ведь не секрет, что в задачах виртуализации именно доступный серверу и виртуальным машинам объем памяти, зачастую, «решает» и задает возможное количество виртуальных машин на хосте.
Наконец, в третьих, в момент принятия решения случилось весьма приятное снижение цен на серверы C-class, которое позволило купить сервера в конфигурации, значительно превышающей варианты других вендоров, и уложиться в строгий и ограниченный «сверху» бюджет.

В результате конфигурирования у нас получилась пара сравнительно недорогих серверов с 96GB RAM, причем такой объем набран недорогими 4GB DIMM (в сравнении с модулями 8GB, которые бы потребовались для такого объема на других моделях). Плюс значительная скидка на данную серию (C-class). Остальные параметры серверов — 4 порта Gigabit Ethernet + 2 out-of-band management Ethernet и два шестиядерных Xeon X5650 (2,66GHz) в каждом сервере. Собственными жесткими дисками серверы не комплектовались.

Выбор серверов от Cisco логичным образом привел к покупке и сетевой части от Cisco. Конечно, на рынке существуют и другие производители сетевого оборудования сравнимых возможностей, тот же HP, но выбирать серверную часть от Cisco и брать при этом какого-то другого сетевого вендора, это уж какой-то чрезвычайный нонконформизм, тем более, повторюсь, полномасштабный проект, к которому данный является «пробным подходом», пилотом и средством обучения и демонстрации, будет использовать сравнительно новые возможности конвергентной сети на коммутаторах серии Cisco Nexus, поэтому не было смысла в пилотном проекте разводить зоопарк и путать «эксплуатантов», поэтому в качестве коммутаторов Level3 были выбраны уже «классические» и хорошо себя зарекомендовавшие в многолетней практике, 24-портовые гигабитные Cisco Catalyst 3750, среди прочего позволяющие cross-stack etherchannel, значительно упрощающий конфигурацию отказоустойчивой IP-сети хранения, которую мы спланировали реализовать.



На базе их создается в тегированных VLAN-ах IP-SAN сеть по протоколу iSCSI, а также используется протокол NFS для подключения датасторов в VMware vSphere. Плюс в них же ходит и собственно сеть виртуальных машин и внешних клиентов.

Итог по аппаратной части выглядел так:



Решение занимает 12RU («юнитов») в стандартном 19”-шкафу, имеет около 5TB дискового пространства (без учета возможной дальнейшей дедупликации, компрессии и использования thin provisioning) и позволяет разместить на нем, расчетно, около 50 виртуальных машин.
Общее энергопотребление – 13,7А, тепловыделение – 9320 BTU/hr, смонтированный вес — 115 кг.
Решение не предъявляет специальных требований к условиям размещения в датацентре.

Редакцией лицензий VMware был, для данного решения, выбран Essential Plus (на момент покупки — 4.1), лицензируемых возможностей которого вполне достаточно для имеющегося оборудования. В версию Essential Plus, напомню, входят лицензии на три физических хост-сервера (в данном решении два, то есть есть запас на расширение) и лицензия на vCenter. Все это отдается за очень небольшие для VMware, деньги, в дальнейшем может быть проапгрейжено до Standard или Enterprise.
Также следует отметить, что аппаратно получившаяся «платформа виртуализации» совершенно нейтральна в отношении выбора гипервизора, не заточена на конкретную версию vSphere, и большинство ее преимуществ и возможностей также будут работать и в Xen, и в MS Hyper-V, что также полезно для «пилотного» проекта.

image

Дополнительно к VMware Essential был куплен продукт vCenter Chargeback, который осуществляет биллинг потребляемых вычислительных ресурсов, генерирует отчеты по их использованию, и так далее.



Я уже говорил, что в этом блоге я не говорю про цены систем хранения NetApp, однако в данном случае могу сказать, что при разработке данного проекта была поставлена заказчиком верхняя бюджетная планка в 100 тысяч USD на все, и нам удалось уложиться в этот лимит, со всей кухней, с стораджем, лицензиями, серверами, коммутаторами, VMware vSphere (на тот момент v4.1), сервисом на сторадж, смартнетом на Cisco, и годовой поддержкой на VMware (и даже немного осталось на обмыв;).

* В Virtualization Pack входят следующие наборы лицензий:
Base Pack + Foundation Pack + Protection Pack + Protection Pack + NFS

BASE PACK (тот, набор, который поставляется с любой системой хранения и включен в ее цену)
Snapshot
FlexVol
Thin Provisioning
RAID-DP
FlexShare
Deduplication
Operations Manager
NearStore
SyncMirror
System Manager
FilerView
FC protocol
iSCSI protocol
HTTP protocol

FOUNDATION PACK
SnapRestore
SnapVault Primary
Provisioning Manager

PROTECTION PACK
SnapMirror
SnapVault Secondary
Protection Manager

SERVER PACK
SnapManager for Virtual Infrastructure
SnapDrive (for Windows, UNIX)
NetApp DSM

И плюс ко всему этому просуммированному набору, в составе Virtualization Set, добавляется лицензия на NFS

Фактически от All Inclusive он отличается отсутствием CIFS, FlexClone и SnapLock (средства создания сертифицированного WORM-хранилища неизменяемых данных) и нескольких софтверных продуктов на хосты.
Tags:
Hubs:
+2
Comments 22
Comments Comments 22

Articles

Information

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