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



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

    Вводная информация по проекту была такая.
    Организация рассматривает возможность создания большого внутреннего «частного облака», на котором планируется оказывать внутренние 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-хранилища неизменяемых данных) и нескольких софтверных продуктов на хосты.
    Метки:
    NetApp 30,18
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 22
    • 0
      И про конкретную реализацию ни слова…
      Написали бы про настройку со стороны СХД (массивы, луны, настройку multipath и загрузки из SAN), производительность системы и т.д.
      Кстати, а для чего там L3-коммутаторы? Для поставленной задачи L2 хватило бы с головой.
      • 0
        > Написали бы про настройку со стороны СХД (массивы, луны, настройку multipath и загрузки из SAN),

        Вообще-то deployment guide это отдельная, и хорошо оплачиваемая задача. И очень большая.
        Например Best Practices Guide для VMware это 97-страничный PDF, для Xen Server 5 — 85 страниц, для VMware View 92 страницы.
        Вы точно хотите это видеть в блоге на Хабре? ;)

        > производительность системы

        Производительность на чем? «Производительность» не бывает сама по себе, она бывает только для конкретной задачи.
        У каждого эти задачи разные, результаты одного, и на одной задаче, обычно мало применимы к другой задаче и другой системе.

        > Кстати, а для чего там L3-коммутаторы? Для поставленной задачи L2 хватило бы с головой.
        Мы будем использовать L3-коммутацию и cross-stack Etherchannel для обеспечения отказоустойчивости, для этого нужны именно они.
        • 0
          Вы точно хотите это видеть в блоге на Хабре? ;)

          Не обязательно пересказывать весь deployment guide, достаточно в пару абзацев описать как и почему оно так настроено.

          Производительность на чем?

          На тех задачах, для которых будет использоваться комплекс.
          • 0
            > Не обязательно пересказывать весь deployment guide, достаточно в пару абзацев описать как и почему оно так настроено.

            www.netwell.ru/production/techbiblioteka.php

            > На тех задачах, для которых будет использоваться комплекс.

            • 0
              > На тех задачах, для которых будет использоваться комплекс.

              Производительность равна 505. :)
            • 0
              > достаточно в пару абзацев описать как и почему оно так настроено.

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

              Но могу попробовать ответить на отдельные конкретные вопросы.
        • 0
          Кстати о ценах — серверы, коммутаторы и софт по листпрайсу стоят чуть больше 1М. Получается, что остальные 2М ушли на СХД.

          итого, с минимальными побочными расходами, «за цену дисков» вендора расшириться до 36 дисков, то есть на 50%

          Красиво написано, вот только «за цену дисков» для радового клиента может стоить ещё около 1М, что составляет 30% от всего бюджета.
          • 0
            > Кстати о ценах — серверы, коммутаторы и софт по листпрайсу стоят чуть больше 1М. Получается, что остальные 2М ушли на СХД.

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

            > Красиво написано, вот только «за цену дисков» для радового клиента может стоить ещё около 1М, что составляет 30% от всего бюджета.

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

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

            В том то и дело, что сумма немаленькая, особенно по сравнению с классическими SAN других вендоров.

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

            50% от листпрайса рядовому клиенту тоже врядли дадут.
            • 0
              > В том то и дело, что сумма немаленькая, особенно по сравнению с классическими SAN других вендоров.

              Она, на сравнимых системах, будет немаленькая в любом случае.

              > 50% от листпрайса рядовому клиенту тоже врядли дадут.

              55 ;)
            • 0
              Спасибо за развёрнутую статью! Думаю пригодится в будущем году при закупке и внедрении СХД в нашей конторе.
              • 0
                Расшифруйте, пожалуйста, для непосвященных фразу:
                > 12 дисков для данной конфигурации явно мало (исходим из количества шпинделей, а не емкости), а 24 — уже, по расчетам, вполне достаточно

                В том смысле, что это за рассчёты? Почему с 12 конфигурация получается несбалансированной?
                • 0
                  Не то что «несбалансированной»…

                  Ну вот смотрите. 12 дисков должны быть поделены на две части, так как два контроллера в HA-кластере, каждый из них, должен владеть своим набором дисков, так как они не «шарятся» между контроллерами.

                  Соответствено в каждой из этих групп по 6 дисков нужно пару дисков отдать под parity (RAID-DP, аналог RAID-6, то есть группа с чередованием и четностью, с двумя дисками четности на RAID-группе).
                  И один диск на каждой группе должен быть hot spare (диски hotspare также не шарятся).

                  Остается при 12 дисках всего 3 + 3 диска под данные (по 3 на каждом из контроллеров). Это мало, причем не столько для объема, сколько для производительности, которая сильно зависит от количества дисков в RAID-группе.

                  Однако если у нас дисков 24, то тогда арифметика другая. Также диски делятся пополам, также один на spare и два на parity на каждой группе, а вот уже все оставшиеся можно целиком использовать под data. Получается 9+9 дисков, то есть эффективной емкости становится уже втрое больше, чем в варианте с 12 дисками. Величина usable от raw уже не 50%, как на 12 дисках, а 75%.

                  К тому же больше становится и дисковых шпинделей, выше будет и производительность на random IO.
                • 0
                  недорогими 4GB DIMM (в сравнении с модулями 8GB, которые бы потребовались для такого объема на других моделях)

                  Это только для Cisco так, для других вендоров цена одинаковая за 2х4GB и 1х8GB. Цена по лист-прайсу (за память) у Cisco в 2 раза больше, чем у конкурентов.
                  Т.е. обоснованность покупки с-серии, только если в дальнейшем будет покупаться b-серия. Но насколько я помню из презентаций (могу ошибаться), софт для управления c-серии и b-серии различный.

                  В данном случае при конфигурировании был заказан так называемый Virtualization Pack*

                  А разве не достаточно было Server Pack? По тексту, требований поддержки приложений (Oracle и т.п.) нет.

                  SAN

                  кстати можно было сделать еще дешевле на Cisco MDS 9124, свич не больше $3000
                  • 0
                    > Это только для Cisco так, для других вендоров цена одинаковая за 2х4GB и 1х8GB. Цена по лист-прайсу (за память) у Cisco в 2 раза больше, чем у конкурентов.

                    Нет, это не так, спорить слишком долго, поверьте, я много вариантов просмотрел.

                    > софт для управления c-серии и b-серии различный.

                    Тоже не совсем так. Есть внутренний менеджер у Cisco UCS C, который работает как HP iLO, напрмер, но для standalone-серверов. Если сервера C-class включить в инфраструктуру B-class, то они вместо этого управляются Cisco UCS Manager для B-class.

                    > А разве не достаточно было Server Pack? По тексту, требований поддержки приложений (Oracle и т.п.) нет.

                    Нужен NFS и VSC/SnapManager for VI (ну или как он там счас называется, VSC Backup and Restore capability plug-in)

                    > кстати можно было сделать еще дешевле на Cisco MDS 9124, свич не больше $3000

                    3560 тоже столько же стоит, а MDS не умеет cross-stack etherchannel, если я не ошибаюсь, а это нам важно, у нас будет много etherchannel-транков в отказоустойчивой «двухфабричной» структуре.
                  • 0
                    Спрошу вещь абсолютно очевидную для Вас, но вот я запутался — а почему сервера Cisco? Из-за некоего софта управления? Или именно из-за поддержки памяти?
                    • 0
                      А мне казалось, что я написал.
                      Конкретно C250 ради большого объема памяти, большего, чем позволяют компактные недорогие сервера других производителей.

                      А конкретно Cisco, оттого, что в будущем в «большом» проекте есть blade-ферма Cisco UCS B-series, в которой есть софт управления Cisco UCS Manager, удобный для наших задач, и который управляет всем парком серверов Cisco, как blade, так и rack.

                      Ну и цена, безусловно.
                      • 0
                        Хм… Скажите, а во сколько примерно обошлись эти замечательные сервера от Cisco? Спрашиваю, потому что только что отложил в сторону GPL — не получилось за обозримое время собрать конфигурацию сервера, чтобы сравнить с тем же HP. Я, признаться, эту линейку у них пропустил — просто не смотрел у них в эту сторону.

                        Софт для управления — безусловно, аргумент.
                        • 0
                          Я бы не хотел тут вовсе распространяться особенно про Cisco, хотя бы потому, что это блог компании NetApp, а не блог компании Cisco :)

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

                          Просто хотел бы отметить, что смотреть GPL не имеет смысла, никто в мире не торгует по GPL, это абстрактные цены, не имеющие, строго говоря, никакого отношения к «уличной», real life цене.

                          Также хочу отметить, что на Cisco UCS C-class весь этот год шла распродажа, и еще будет идти, как я понимаю, с очень большими скидками на ряд преконфигурированных моделей. И если вы попадаете по своим желаниям в такую преконфигуренную модель, то покупать именно ее по такой промо-программе будет очень выгодно.
                    • 0
                      Спасибо. Отличная статья. Все доходчиво и понятно, тем более я как раз после SAN IW :)

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое