company_banner

Как железо Dell ездит, монтируется и обслуживается + пример внедрения



    У нас относительно недавно открылся первый в РФ центр решений Dell — место, где развёрнута инфраструктура (софт плюс разное железо) от этого производителя. Но рассказывать я буду не столько про него, сколько про то, как оборудование собирается, везётся и что делать, если из корпуса вдруг пошёл дым, и для чего в России нужны «миниЦОДы под столом».



    А пока знакомьтесь — стойка Active System у нас выглядит следующим образом:
    • 1 блейд-шасси Dell PowerEdge M1000e — 9 вентиляторов, 6 БП 2700 Вт;
    • 2 блейд-коммутатора Dell MXL 10/40GbE — внешних портов на коммутатор — 2 по 40 Гб/c без дополнительных модулей, FTOS — 9.2, 6 кабелей DAC;
    • 6 блейд-серверов Dell PowerEdge M620 — 2 процессора E5-2660, 128 ГБ оперативной памяти (8 по 16 ГБ, 1600 МГц), BRCM 10GbE 2-Port 57810, PERC S110, Dual SD Card;
    • сервер Dell PowerEdge R620 — 1 процессор E5-2620, 96 ГБ оперативной памяти (6 по 16 ГБ, 1333 МГц), BRCM 10G/GbE (2+2)-Port 57800, PERC S110, Dual SD Card;
    • СХД Dell EqualLogic PS6110XS — RAID 6 Accelerated, 7x400 ГБ SSD, 17x600 ГБ 10K SAS;
    • 2 оптических коммутатора Dell Force10 S4810.


    Сервис


    Dell — компания не российская, поэтому сервис делают партнёры здесь. Мы — один из ключевых партнеров Dell, работаем с вендором уже 10 лет и реализовали совместно около 400 проектов, плюс у нас самый большой склад резервных запчастей. Сервис работает 24/7, на железо и комплексные системы (ПАКи) по умолчанию действует 3-годичная гарантия от вендора, которая может расширяться до 7 лет.

    Сервисный контракт можно поддерживать и с нами, у нас же есть и склад запчастей. Там же есть и «приветы» из 90-х, которые могут реально кому-то понадобиться.


    Склад

    Время реакции по стандартной гарантии — 1 рабочий день от регистрации инцидента до восстановления работы системы. Для критичных сервисов уровня банковских время реакции — 4 часа (по Москве), поэтому у нас есть специальная «летучая» инженерная смена для нашего центра Dell и других вендоров. Понятно, что во Владивостоке или Новосибирске за 4 часа ничего не поднять, но если надо — прилетим и туда с железкой ближайшим рейсом.

    Монтаж


    Железо такого уровня редко поставляется серийно. Каждая модель собирается под конкретного заказчика и конкретный приклад.

    Если речь про VRTX (это такой мини-ЦОД в едином корпусе, размеры которого не превышают размеров тумбочки, он помещается под столом, не требует спец.охлаждения и включается в обычную розетку 220 В), то он полностью собирается в Европе на одном из крупных производственных узлов Dell.

    Пример конфигурации VRTX:
    • блейд-шасси Dell PowerEdge VRTX — 6 внутренних и 4 внешних вентилятора, 4 БП 1100 Вт;
    • 3 блейд-сервера Dell PowerEdge M520) — 2 процессора E5-2420, 32 ГБ оперативной памяти (4 по 8 ГБ, 1333 МГц), Broadcom Gigabit Ethernet BCM5720, PERC H310 Mini;
    • 6 дисков 300 ГБ 15К SAS;
    • 6 дисков 300 ГБ 10К SAS;
    • блейд-коммутатор R1-2401 VRTX 1Gb;
    • видеокарта AMD FirePro V9800P;
    • сетевая карта Intel 10GbE 2-Port X520.

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

    Стойку нельзя трясти, нельзя наклонять больше чем на 30 градусов (обычно), нельзя ронять, нельзя мочить. Плюс за транспортировкой таких вещей полезно следить по карте, если кузов фуры пробивается сотовым сигналом. Если стойку наклонить или потрясти, могут выйти из строя диски, может полететь что-нибудь в смонтированных строго вертикально или горизонтально платах. Учитывая характер нагрузок (постоянные и высокие, то есть в критическом для обычного оборудования режиме), стойка потом будет сбоить. Вот почему по любому из датчиков сразу же слетает дорогостоящая гарантия.

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

    Стенд Active System — это одна или несколько стоек, которые собираются также под заказчика, но уже из модулей на нашей стороне. Мы получаем сетевое оборудование и ПО на склад, монтируем в стойку, тестируем, обвешиваем датчиками и везём собранной по предыдущему сценарию. Заказчик получает его уже в собранном виде, настроенном под конкретные задачи, например, под задачи VDI, управление доступом или диагностику производительности.


    Роутер стойки в тестовой зоне. Видно свободное место.

    Расчёты


    Обе системы используются для серьёзных корпоративных задач. VRTX обычно — для максимально быстрого и простого развёртывания нескольких сервисов типа Exchange на несколько сотен пользователей, либо обсчёта 3D-графики для анимационной студии, а также других задач такого класса. Купил, поставил, включил в розетку, подвёл сеть, поковырял 3–4 дня и забыл. Стоит, работает, и мы за всем следим.

    Весит миниЦОД не больше 70 кг. Это максимум, до чего его можно забить. Вес пустой корзины – около 25 кг.

    Active System используется под высоконагруженные приложения вне зависимости от сферы деятельности компании, будь то финансовая, нефтяная, медицинская и другие сферы. Плюс, такая система пригодится под виртуализацию розницы и рабочих мест в крупных компаниях. В общем, кусок своего ЦОДа или ЦОД целиком.
    Физически это тоже довольно лёгкая стойка — на 213 килограммов (по примеру конфигурации вверху, Compellent — 19,73 кг + R620 25 кг + блейд-серверы + корзина 80 кг + 6*7 кг + СХД EqualLogic PS6110XS — 26 кг + полка к Compellent примерно 20 кг). То есть трое-четверо мужчин могут легко поднять.

    Тепла она выделяет — 2765 Вт/час.
    Максимальное энергопотребление — 2766 Ватт.

    Пример использования Active System


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

    Основной функционал — выделение пользователям физических машин, управление активами, управление конфигурациями аппаратуры и ПО, инсталляция ОС и приложений. В результате аудита было предложено решение по построению виртуальной инфраструктуры (VDI) на оборудовании Dell.

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

    В качестве вычислительной мощности используется следующее оборудование Dell:
    • 16 блейд-серверов Dell PowerEdge М620 (2 х Intel Xeon E5-2670v2 \192Gb Memory) — основные мощностные ресурсы;
    • 2 сервера Dell PowerEdge R620 (Intel Xeon E5-2630v2), необходимые для управления вычислительными мощностями;
    • внешние дисковые хранилища общим объёмом до 51,6 ТБ; СХД Dell Compilent SC8000.


    Софт такой:
    • брокер подключения vWorkspace;
    • гипервизор VMware (или Microsoft Hyper-V);
    • Active System Manager.


    Пользователи могут применять тонкие клиенты для доступа к своим виртуальным ПК. В данном проекте используется Dell Wyse D10D. Как вы уже обратили внимание, для построения инфраструктуры мы используем всё оборудование и ПО от одного вендора. Это несомненный плюс, поскольку система поддерживается у одного производителя и является комплексным решением, за которое отвечает исполнитель. Целиком и полностью. Это было нужно по вводной «некоторый хаос». Дело в том, что Dell, пожалуй, — единственный вендор, который может предложить столь полный портфель для подобного рода задач. И софт, и железо поставляются и обслуживаются в рамках одной компании, и если где-то возникает проблема, её решают, а не ищут виноватых в другом подразделении.

    Таким образом, используя VDI, заказчик получает непрерывность бизнес-процесса (рабочие места доступны в любое время и из любого места), сокращение затрат на приобретение и обслуживание физических ПК, увеличение уровня информационной безопасности. Заказывается 4-часовой SLA, что сильно радует сотрудников заказчика, контролирующих риски. Также в плюсах — упрощение инфраструктуры и системы управления нагрузкой (нет ненужных простаивающих мощностей), обеспечение гибкости и масштабируемости с прицелом на будущее, гибкость в выборе конфигураций (набор железа компонуется в каждом конкретном случае), внедрение у заказчика в сжатые сроки. Система настраивается на стороне исполнителя-интегратора, то есть точка входа по сервисной поддержке единая (КРОК + Dell).

    Стоимость одного рабочего места выходит примерно в 4–5 тысяч долларов в зависимости от конфигурации (это ориентировочная стоимость по условному прайс-листу, от которой возможны серьезные скидки). По размерам система помещается в стойке 42U.

    Центр решений


    У нас есть и VRTX для среднего бизнеса, и более дорогой (примерно на порядок дороже) AS для крупного бизнеса. Можно посмотреть их, потестировать на них свои прикладные сервисы (в том числе и по своей собственной программе, если есть такая необходимость), оценить работу на симуляторе под нагрузкой. Если интересно — пишите на nsofronova@croc.ru, расскажу подробнее про центр решений Dell.
    КРОК
    IT-компания

    Комментарии 29

      0
      Тепла она выделяет — 2765 Вт/час.
      Максимальное энергопотребление — 2766 Ватт.

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

        0
        Хм. Я вижу, что я возможно не прав, но не пойму, где…
          +2
          Наверно считать так: максимальная эффективность в качестве обогревателя такая-то.
        0
        Стоимость одного рабочего места выходит примерно в 4–5 тысяч долларов

        Что здесь понимается под одним рабочим местом? Цена одной вм для эндюзера?
          0
          Это затраты на оборудование, софт, лицензии на софт, работу по настройке, поделенные на общее количество пользователей.
            0
            не дороговато ли?
              0
              Выше указано, что это цена по прайсу. Она почти всегда существенно меняется вниз (и достаточно сильно).
              0
              1000 юзеров * 4к$ за одного = ой, мамочки… Или не правильно считаю?
                +1
                А никто и не говорил, что VDI — это дешево. Да еще это и очень хрупкая штука, легко сломать.
                  0
                  Вот меня, если честно всегда поражали такие решения. Мне всегда кажется что единственная область их применения это компании, которые хотят ОЧЕНЬ надежно, все равно за какие деньги.
                    +1
                    Я знаком с одной очень крупной и всем известной компанией, у которой на НЕДЕЛЮ был парализован весь VDI. В их случае это — половина рабочих мест. Т.е. половина сотрудников целую неделю пялилась в черный экран. Правда, в новости это почему-то не попало. Или я плохо искал.

                    Никакого отношения к повышению надежности VDI отродясь не имел, это — огромная единая точка отказа.

                    Вот упрощение менеджмента пользовательского окружения — да.
                      0
                      А зачем тогда её проектируют как единую точку отказа?
                      Я не большой специалист в этом, но в моем понимании — есть хранилище, которое можно реплицировать (не обязательно аппаратное), есть серверы приложений, от которых вообще ничего не зависит — сломался, выкинули, запустили на соседних, и есть сеть, которая дублируется. Разве что управляющий софт.

                      А, да, и ещё «тонкие клиенты» которые стоят в 5-10 раз дороже аналогичных по железу неттопов.
                        0
                        Вот массивы и являются наиболее стремным местом (кстати, в рамках VDI их производительности никогда не будет хватать).

                        Если помните, даже у гугла даже распределенные хранилища ломались, и приходилось доставать информацию с лент.
                          0
                          Да за эти хралища ломят такую цену, что дешевле делать x3 репликацию + бекапы.
                            0
                            Репликацию чего?
                              0
                              брать обычные sataшки, в количестве втрое больше, чем надо, и делать на них raid1 с тремя репликами
                                0
                                Ну-ну. Вы в курсе, какие у VDI требования к IOPS? Серьезные дисковые массивы зашиваются, флеш-массивы худо-бедно тянут, но стоят не две копейки. И это еще если не говорить о том, какими глюками чревато разворачивание этого дела на обычных SATAшках. Знаете например одно из главных их отличий от серверных винтов? Серверный винт, как только почувствовал малейшие признаки неполадок, сразу же гаснет и требует замены. Хомячкового класса накопитель будет скрежетать блинами до последнего, сыпля кучей ошибок и вызывая колоссальные проблемы. Так что нет, не ентерпрайзненько. Да и если вы напихаете десятки SSDшек (объем-то нужен) в обычный сервер, то получите тот же массив, только чертовски ненадежный и тормозной.

                                А если мы говорим о приличном по размеру внедрении VDI, то мы говорим о множестве блейдовых корзин с виртуализацией. А к ним для удобства, надежности и производительности любят цеплять FC массивы. Ага, они дорогие.

                                Можно для пущей надежности держать на одной локации два массива с непрерывной репликацией данных между ними. Только и это не покрывает большинство сценариев отказа.

                                Да и вообще… Вот распиаренный Violin например с мегаиопсом. Коллеги, изначально ссавшие от него кипятком, чуть разочаровались, узрев, что обновление может длиться десятки часов, при этом latency растет до десятков-сотен миллисекунд на все время обновления…

                                Что до рейдов… Нет, развал массива из-за отвала нескольких дисков — как раз наиболее редкий вариант отказа. И наиболее идиотский на самом деле.
                                  0
                                  Спасибо за развернуй комментарий.

                                  требования к IOPS, имеют смысл, если хранилище — одно. Зачем делать одно хранилище, если потребителей всё-равно множество?

                                  Почему нельзя взять ноды из расчета 2 диска на каждые X (4 например) виртуалок, с репликацией блочный девайсов на соседние ноды?

                                  И, кстати, Вы сказали, что отказ дисков — редкая проблема, а какие частые?
                                    0
                                    Зачем делать одно хранилище, если потребителей всё-равно множество?

                                    Тогда вы будете вынуждены держать на всех хранилищах копии одних и тех же данных, что неэффективно и вообще дорого.

                                    Далее. Вот у вас десять тысяч виртуалок под VDI. Сколько возьмете серверов под хранение данных, сколько — под саму виртуализацию, и сколько будете платить за такое количество рядов стоек? А какая-нибудь виолончель с десятками терабайт очень быстрого хранилища занимает вроде три юнита, и выйдет наверняка дешевле даже в плане простой закупки, без эксплуатационных затрат.
                                      0
                                      Тогда вы будете вынуждены держать на всех хранилищах копии одних и тех же данных, что неэффективно и вообще дорого.

                                      Да ладно! А RAID — это тоже «неэффективно и дорого»? А какие варианты вообще есть, если единичное устройство по физическим причинам не может быть достаточно надёжным и/или производительным?
                                        0
                                        Так и с кластером много чего может случиться. Но чем больше вы размазываете кластер горизонтально, тем больше теряете денег.
                                    0
                                    Хомячкового класса накопитель будет скрежетать блинами до последнего, сыпля кучей ошибок и вызывая колоссальные проблемы.

                                    неверно — хомячковые диски поддерживают ERC

                                    А к ним для удобства, надежности и производительности любят цеплять FC массивы. Ага, они дорогие.

                                    а ещё 10G Ethernet, который внезапно дешевле.

                                    И вообще, я не предлагаю «вставить три диска в один сервер». Пусть это будет три сервера, CEPH и QEMU, который нативно поддерживает тома RBD.

                                    Так что нет, не ентерпрайзненько.

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

                                    Я предлагаю маркетологический спор прекратить и перейти к технологическому. Не «там железки за млн баксов не справляются, а вы тут за тыщу хотите решить проблему», а «там железки используют такие и такие методы и не справляются, а вы тут хотите внедрить те же методы, но в ослабленном варианте».
                                      0
                                      а ещё 10G Ethernet, который внезапно дешевле.

                                      Только он будет ложиться куда чаще, чем выделенная FC сеть с SAN A и SAN B. А кратковременный отвал дисковой подсистемы — большая неприятность для виртуалки.
                                      Пусть это будет три сервера, CEPH и QEMU, который нативно поддерживает тома RBD.

                                      QEMU? А VMWare View, самое зрелое и наиболее популярное решение под эту задачу, можно?
                                      Ненавижу махровый энтерпрайз. Вместо решения проблем — куча дополнительных за бешенные бабки

                                      Наколенные решения могут работать хорошо на десятке пользователей, но если у вас их десяток тысяч (как у той упомянутой выше компании), то намного дешевле будет выбрать нечто ентерпрайзное. Есть неиллюзорная вероятность, что опенсорс не сможет масштабироваться до нужных значений и завалится под собственным весом.
                                        0
                                        Только он будет ложиться куда чаще, чем выделенная FC сеть с SAN A и SAN B.

                                        С какой бы это стати? Ни тот, ни другой не будут ложиться. Только для FC железо чуть дороже и чуть более экзотическое.

                                        QEMU? А VMWare View, самое зрелое и наиболее популярное решение под эту задачу, можно?

                                        Нет, нельзя. Ни разу не видел глючащего qemu (на поверку оказывались проблемы в ОС внутри контейнера), вот глючащих вмварей видел дофига, при том, что куему я видел гораздо больше.

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

                                        Как раз с точностью наоборот, практика везде показывает, что ынтерпрайс помимо невероятной неадекватной сложности ещё и невероятно тяжёл. Почему-то постгрес я могу завести на чуть ли не роутере с 128 мб памяти, и он вместится в пятьсот метров на диске вместе с операционной системой (не считая данные), и будет работать, а вот оракул и мсскл мало того, что сожрут десятки гигабайт на диске, так ещё и тормозить будут на таком же по производительности железе дай боже, если вообще запустятся. Не выигрывают они и на другом конце, на топовом железе: ораклы падают и в сбербанках, и они потом не могут понять, что случилось, и постгресы крутятся в инстаграмах и яху и вполне тянут нагрузку.

                                        намного дешевле будет выбрать нечто ентерпрайзное

                                        ну давайте не будем снова, известная кампания про якобы более низкую совокупную стоимость владения ынтрепрайзом уже давно слилась с позором
                                          –2
                                          Ни тот, ни другой не будут ложиться.

                                          То есть не бывает глюков софта в железе, не бывает хитрых непредусмотренных сбоев, не бывает переходных сбоев при перестроении топологии? Забавно. И уж сколько костылей для ethernet придумали, чтобы FCoE, требующий 0 потерь, мог работать…
                                          Ни разу не видел глючащего qemu (на поверку оказывались проблемы в ОС внутри контейнера), вот глючащих вмварей видел дофига, при том, что куему я видел гораздо больше.

                                          А qemu вообще что-нибудь умеет по сравнению с View? И в каких масштабах вы с ним работали?
                                          Почему-то постгрес я могу завести на чуть ли не роутере с 128 мб памяти

                                          Хомячковая логика. Малое потребление ресурсов при малых масштабах ничего не говорит о способности работать с крупными масштабами — тут у оракла конкурентов нет, выше только MapReduce со своими проблемами. У Сбера, кстати, оракл падал из-за глупой ошибки, даже нескольких. А по Yahoo: «for performance, storage, and query purposes the database bears little resemblance to PostgreSQL». Перепилено до основания, и используется только для аналитики, а вовсе не для real-time задач.
                                          известная кампания про якобы более низкую совокупную стоимость владения ынтрепрайзом уже давно слилась с позором

                                          Это вам так кажется, потому что вы привыкли колхозить и не привыкли к крупным масштабам :) В рамках большинства задач нельзя сложить вместе тысячу или даже миллион Raspberry Pi и получить аналог одного топового HPшного сервера.
              +1
              Тепла она выделяет — 2765 Вт/час.
              Максимальное энергопотребление — 2766 Ватт.


              А куда девается оставшийся 1 Вт?
                –1
                На единицы измерения посмотрите внимательнее.
                  0
                  Нет, вы.
                  Ватт — это единица измерения мощности (энергию делим на время).
                  Энергопотребление не измеряют в ваттах, его измеряют в Вт*ч.
                  Вопрос про 1 Вт в силе.
                  0
                  меня ещё интересует с каких пор тепловыделение стало в ваттах разделённых на час (в то время, как ватт — это уже джоуль разделённый на секунду), вместо того, чтобы в джоулях (ну, или хотя бы в ваттах, умноженных на час (что уже является «почти джоулями», в которых тепловыделение и правильно было бы измерять.

                  Так что, да, учитывая поправку выше про потребление в ватт-часах — присоединяюсь к вопросу про потерявшийся ватт (наверное, съел Демон Маквелла ☺)

                  [OFFTOP]
                  P.S. Уважаемый хабр в лице твоих разработчиков, прекрати, пожалуйста, разбивать юникодные символы U+1F6[0-4][0-9] на пучок «алмазов» при предпросмотре и публикации коммента. Они являются единым символом. Хз, зачем их ломать парсером…
                  Уже который раз хочу употребить один или несколько оных символов и наблюдаю фейл ☹
                  [/OFFTOP]

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