Облако с нуля с использованием XenServer

    Недавно мы создали небольшое облако для решения наших внутренних задач и хотим поделиться этим опытом с читателями Хабра. Здесь мы подробно опишем, какое оборудование было выбрано для развёртывания облака и как создать инфраструктуру облачной системы, опираясь на XenServer от компании Citrix. В этом продукте Citrix решила отказаться от стандартного подхода, когда у облака есть некоторый центральный управляющий узел, они разбили его на несколько составляющих и предложили их тоже поместить в облако. Кому интересно, как это всё работает — добро пожаловать под кат!



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



    Подготовка аппаратной части


    Первой задачей становится выбор основы для любого облака, а именно — выбор серверов, на которых будет производиться виртуализация. Мы остановили свой выбор на серверах от компании IBM и выбрали IBMx3850 X5.
    Каждый IBM основан на IBM X-Architecture и имеет:
    • 4 процессора Intel® Xeon® CPUE7- 8860 с тактовой частотой 2.27GHz, что в итоге даёт 40 ядер на сервер (80 потоков);
    • 150Гб RAM;
    • 2 независимых блока питания;
    • карту расширения fibre channel;
    • сетевую карту для 10-гигабитного соединения;
    • 2 жестких диска по 500Гб, объединённых в RAID1.

    Дальше возникает вопрос: где хранить виртуальные машины? Если их хранить на самих серверах, то это уменьшает надёжность системы, т.к. при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём. Также такой подход сильно усложняет задачу балансировки нагрузки, потому что миграция виртуальной машины потребует перемещения её диска на другой сервер, а это — достаточно долгий процесс. Поэтому в нашем стенде используется внешнее хранилище DELL md3620f, оснащённое 4 выходами fibre channel. Это хранилище поддерживает до 24 жестких дисков, которые могут быть объединены во все популярные типы рейдов(RAID0, RAID1, RAID5, RAID6, RAID01). Мы в нашем случае используем 10 жестких дисков по 1ТБ, объединённых в RAID5.

    Что требуется для быстрой миграции? Для обеспечения быстрой миграции между IBMами в состав стенда был добавлен 10гигабитный коммутатор summit x670, это теоретически должно было ускорить миграцию (самый долгий процесс в миграции – передача данных по сети от одного сервера к другому) в 10 раз, но на практике это дало выигрыш только в 5-6 раз. Чтобы у серверов и виртуальных машин был доступ в локальную сеть и Интернет, в состав стенда был добавлен коммутатор HP ProCurve.Также через него идёт трафик к внешним клиентам.

    Подводя итог по аппаратной части, мы имеем стенд, включающий в себя:
    • 4 сервера IBMx3850 X5
    • коммутатор HP ProCurve для соединения до 1000 Мб/сек
    • коммутатор Summit x670 для поддержки соединения 10Гбит/сек
    • внешнее хранилище DELL md3620f с 10Тб дисковым массивом
    • и прочее (источник бесперебойного питания APC Smart-UPS 3000VA, трансиверы для оптоволокна, восемь десятиметровых оптоволоконных кабелей, 50 метров витой пары )

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

    image

    Логическая схема соединения выглядит следующем образом:



    Если суммировать, то мы имеем:
    • 160 вычислительных ядер (320 потоков);
    • 600Гб RAM;
    • 14ТБ дискового пространства;
    • Высокоскоростную сетевую инфраструктуру.

    Установка XenServer


    Для запуска виртуальных машин на выбранном нами железе, было решено развернуть облачную платформу XenServer Platinum.
    Краткая общая информация о XenServer, если кто не сталкивался: XenServer — это самостоятельная операционная система, основанная на ядре Linux. В основе всего лежит гипервизор XEN, последняя на данный момент версия — используемая версия XenServer 6.1 — основана на гипервизоре XEN 4.1. Для нормальной работы системы необходим процессор с поддержкой виртуализации и 1Гб RAM. Ребята из Citrix не любят писать свои минимальные требования, предпочитая писать максимальные системные требования, с ними можно ознакомиться тут. В семейство XenServer входит несколько версий продукта, отличающиеся ценой и дополнительными функциями.

    На все сервера IBM необходимо установить XenServer. Сама установка XenServer является совершенно несложным процессом и не очень отличается от установки Ubuntu. Куда больший интерес представляет настройка системы для последующей удобной работы, что и будет рассмотрено дальше, основное внимание будет уделено компонентам расширения для XenServer, которые предоставляет Citrix. После установки XenServer на все хосты необходимо зайти в XenCenter (его можно скачать, зайдя на web-интерфейс установленного XenServer или с сайта Citrix). В XenCentеr необходимо создать пул и добавить к нему сервера.

    Установка лицензии


    После установки XenServer первым делом нужно установить лицензии на сервера. Это делается не с помощью ввода лицензионных ключей, а с помощью установки сертификата, полученного в личном кабинете на сайте Citrix. Сертификат представляет собой текстовый файл с лицензионными ключами, записанными в специальном формате. Его можно получить сразу на несколько серверов. Сертификат необходимо установить в специальный центр лицензирования. Тут стоит отметить, что если хотя бы один из сертификатов является не валидным, то все сертификаты не будут действовать.



    Citrix предлагает установить центр лицензирования либо на отдельном хосте, либо на виртуальной машине в вашем облаке (она почти не потребляет ресурсов процессора и требует всего 256 Мб оперативной памяти). Но если вы установите его как виртуальную машину, вас могут ожидать неприятности. Однажды вы можете столкнуться с проблемой, с которой столкнулись мы, когда отключили сервера нашего стенда для их апгрейда, а вместе с ними выключилась, соответственно, и виртуалка с центром лицензирования. После включения XenServer выдал ошибку «Кончился срок пробной лицензии» (центр лицензирования ведь был не запущен). Вроде проблем быть не должно: просто включить виртуальную машину центра лицензирования с нормальной лицензией и принять её. Но не тут-то было: с истёкшей лицензией нельзя включить НИКАКУЮ виртуальную машину. Правда, после первоначальной паники в меню принятия лицензии была найдена кнопка «активировать бесплатную версию», после нажатия которой мы увидели фразу «у вас осталось 30 дней пробной лицензии». И уже потом можно запустить виртуальную машину с лицензией.



    Создание виртуальной сетевой инфраструктуры


    Чтобы гибко управлять сетевыми настройками виртуальных машин и чтобы они не были в одной подсети с серверами XenServer, необходимо наладить виртуальную сетевую инфраструктуру. Для этих целей у Citrix предусмотрен компонент Distributed Virtual Switch Controller (DVSC). Он также предоставляется в виде виртуальной машины, но она потребляет уже больше ресурсов: 2 VCPU и 2Гб оперативной памяти. Настройки DVSC не представляют собой ничего сложного: необходимо указать свободный IP-адрес для виртуальной машины, после чего добавить пул к DVSC.Всё это делается через web-интерфейс. После этих действий появляется возможность создавать виртуальные сети между виртуальными машинами, находящимися на разных серверах (Cross-ServerPrivateNetwork), тогда как до этого было возможно создавать виртуальные сети только в рамках одного сервера (Single-ServerPrivateNetwork).



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



    Также DVSC может выступать в роли простого межсетевого экрана, правила которого можно создавать во вкладке AccessControl. Все политики сетевой безопасности делятся на 4 уровня: глобальные политики (т.к. к одному DVSC могут быть подключены несколько пулов), политики пула, политики конкретной сети, политики конкретной виртуальной машины. Правила описывают тип действия (разрешить или запретить), протокол (можно задать порты получатели и отправителя или указать известный протокол) и для кого это правило применять.

    В работу межсетевой экран вступает сразу после установки, и в нём сразу записаны 4 базовых глобальных правила:
    • разрешать все ARP-сообщения в сети
    • разрешать виртуальным машинам получать IP-адрес по dhсp
    • разрешать виртуальным машинам обращаться к DNS-серверам
    • разрешать весь сетевой трафик (это правило применяется после проверки всех правил других уровней)



    Вообще DVSC всем хорош, и по функционалу чем-то напоминает vShield Edge от VmWare, но Edge кажется удобнее за счёт разных мелочей: возможности создания DHCP-сервера, удобной организации Nat для виртуальных машин и т.д. Всё это (отсутствие DHCP-сервера и Nat), конечно, решается с помощью создания отдельной виртуальной машины на базе Ubuntu, но удобно, когда всё уже решено заранее.

    Проблема с созданием виртуальной машины с Ubuntu


    Вообще создание виртуальных машин с Ubuntu в первый раз вызывает шок и непонимание — как такое попало в релизную версию продукта? Дело вот в чём:



    После создания виртуальной машины из стандартного шаблона она не может запуститься и пишет указанную выше ошибку (Error code: INVALID_SOURCE). Ошибка связана с параметрами загрузки виртуальной машины. Бороться с ней можно следующим образом(описание взято тут и чуть-чуть модифицировано для работы с большим числом виртуальных машин):
    1. Зайти в консоль XenServer, что можно сделать через XenCenter (вкладка Console у сервера) или по ssh.
    2. Узнать uuid виртуальной машины командой xe vm-listname-label=[НАЗВАНИЕ_ВМ]. В нашем примере это выглядит так:



    3. Дальше необходимо установить параметры загрузки следующей командой: xe vm-param-setuuid=[UUID_ВМ] HVM-boot-policy=BIOS\ orderHVM-boot-params:order=dc.
    4. После этих несложных манипуляций виртуальная машина успешно запустится.

    Но на этом ошибки, связанные с работой Ubuntu, не заканчиваются. При создании нашего стенда было принято решение создать шаблоны виртуальных машин с разными ОС, чтобы не тратить время на установку нужной, а сразу брать готовую и туда ставить уже необходимое ПО. С машинами на базе Windows нет никаких проблем, тогда как с Ubuntu возникает проблема чёрного экрана при создании виртуальной машины из образа. Решение этой проблемы оказалось довольно простым, с одной стороны, и немного неправильным, с другой. Проблема решается простой установкой xen-tools на виртуальную машину. Минус такого решения в том, что невозможно предоставить чистую операционную систему, что иногда требуется в рамках решаемых задач.

    Динамическая балансировка нагрузки


    В рамках решаемых задач часто нужна динамическая балансировка нагрузки между серверами с XenServer. Для этих целей компания Citrix предоставляет виртуальную машину Citrix WLB Virtual Appliance, которую также необходимо добавить в облако, после чего произвести простую настройку через её консоль (при заходе в консоль все необходимые действия машина подскажет сама). После этого нужно зайти в XenCenter и указать пулу, что именно эта виртуальная машина будет отвечать за балансировку нагрузки между серверами (это действие производится во вкладке WLB).



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

    Настройка и разграничения доступа к облаку


    Последней задачей, которую необходимо решить для нормальной работы, является предоставление доступа к облаку. И тут у Citrix, на наш взгляд, самые большие проблемы. Citrix предлагает два варианта получения доступа к облаку: через XenCenter и через web-интерфейс.

    Доступ через XenCenter

    Если к пулу подключить Active Directory (AD), то появляется возможность создавать пользователей в XenCenter. Компания Citrix решила отказаться от дискреционной модели доступа в XenCenter и реализовала ролевую. Отсюда основная проблема: ВСЕ пользователи видят и имеют доступ ко ВСЕМ виртуальным машинам, регулируется только тип доступа, но он применяется ко ВСЕМ виртуальным машинам сразу (т.е. если даётся роль на запуск виртуальных машин, то сразу всех). Также стоит отметить, что AD должен постоянно быть доступен, т.к. при перезагрузке AD автоматически не добавляется к пулу, и его необходимо каждый раз добавлять вручную.

    Доступ через web-интерфейс

    Для дискреционного доступа компания Citrix предлагает использовать доступ через web-интерфейс. Для настройки доступа через web-интерфейс необходимо установить виртуальную машину Citrix XenServer Web Self Service. После простой настройки виртуальной машины через её консоль (необходимо задать ip-адрес или указать, чтобы он получался по DHCP) необходимо выполнить ряд настроек через web-интерфейс. Тут Citrix выше всяких похвал за доступное и понятное описание: если вы вошли в качестве администратора, вам сразу будет показан список шагов, которые необходимо выполнить, а также подробно описано, как это делать.



    В Citrix XenServer Web Self Service могут использоваться те же пользователи, что есть в AD, или создаваться новые. При первой загрузке XenServer Web Self Service администратору необходимо указать, как он хочет действовать, и это решение уже потом никак нельзя изменить (конечно, всегда можно переставить виртуальную машину, но это повлечёт за собой новую настройку прав доступа к виртуальным машинам). После настройки любой пользователь может получить доступ к конкретной виртуальной машине через браузер. И тут Citrix тоже очень радует: для работы может быть использован любой браузер, а не какой-то ограниченный набор, как у облака от Microsoft (только InternetExplorer) или VmWare (не поддерживается Opera). Для того чтобы пользователь получил доступ к виртуальной машине, администратор должен разрешить доступ к этой виртуальной машине для данного пользователя, что легко делается через web-интерфейс.



    К большим недостаткам работы через web-интерфейс можно отнести невозможность настройки физических параметров виртуальной машины (количество процессоров, количество RAM, настройка подключённых сетей и жестких дисков). Так что web-интерфейс – это доступ к графическому интерфейсу виртуальной машины, а не к управлению её физическими параметрами. Мы выполнили все необходимые действия: подготовили аппаратуру, настроили лицензии, развернули… И теперь облако готово к работе!

    Наш эксперимент


    Для оценки реальной вычислительной мощности серверов мы провели эксперимент, целью которого было максимально загрузить все 80 логических ядер на системе. В качестве основы для проведения эксперимента была взята программа, выполняющая Ray-Tracing простой сцены, без операционной системы и использующая все ядра на всех процессорах в компьютере. О том, как работает эта программа и как получить исходные коды этой программы, можно прочитать тут.

    Для эксперимента программа была немного доработана: добавили анимацию движения для одной из сфер на рисунке, добавлен подсчет скорости работы, и добавлена буферизация при рисовании каждого кадра. Для сравнения мощности работы полученной программы мы запускали ее на нескольких компьютерах разной конфигурации, в том числе, и на наших IBM серверах. В эксперименте выполнялся рендеринг сцены из 5-ти сфер в разрешении 800x600. Эксперимент увенчался успехом и IBM сервера показали внушительные показатели производительности. Для всех экспериментов мы записали видео, где цифры зеленого цвета в левом верхнем углу экрана означают количество кадров в секунду (FPS), цифры красного цвета — количество секунд на кадр. Вот такие результаты мы получили:

    1. Обычный компьютер: Intel i3-2100, 3.1 GHz, всего 2 ядра. Для каждого ядра 800x600/2=240000 точек на кадр. Как видно из видео, скорость составила примерно 0.5 FPS (на один кадр тратилось более 2-х секунд).



    2. Компьютер на современном мощном процессоре: Intel i7-4770, 3.4 GHz, всего 8 ядер. Для каждого ядра 800x600/8=60000 точек на кадр. Результат — примерно 2 кадра в секунду, как можно видеть на видео.



    3. IBM сервер из стойки: Intel Xeon E7-8860 2.3 GHz, на каждом компьютере по 4 процессора по 10 физических ядер (на каждом ядре 2 логических) — итого 80 ядер. Для каждого ядра 800x600/80=6000 точек на кадр. Результат — 12-14 FPS — что значительно больше, чем у других систем.



    Интересно, что если запустить на IBM сервере рендеринг в разрешении 1280x1024, и позволить ядрам процессора работать без буферизации, то можно заметить, как кадр рисуется из 80-ти полосок!



    Вот что у нас получилось. Надеемся, что, прочитав нашу статью, вы сможете легко сделать облако сами, избежав тех проблем, которые мы здесь описали, или успешно справившись с ними!
    НеоБИТ
    99,27
    Компания
    Поделиться публикацией

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

      0
      Почему RAID-5, а не, н-р, 6?
        0
        Не храним там настолько критичные данные, чтобы терять в памяти и скорости при использовании RAID6.
        Баланс между скоростью, памятью и надёжностью.
          0
          Тогда уж не 5 и не 6, а 50, ака «полтосик» :)
            –1
            RAID-50 не добавляет надежности к и так неприемлемому уровню RAID-5, только производительность.
              +1
              Если уж подходить формально, то все-же добавляет — можем потерять по одному диску в каждой 5ке из которых собран 0.
              Но от DoR это конечно не спасет. Хотя я разок видел DoR и на 6ке — диски из одной партии дружно посыпались.
              Все равно резервное копирование и еще раз резервное копирование :)
            0
            Потеря в объёме будет ровно в один диск, если массив например из 12 дисков по 500 Gb, то RAID5 будет объёмом в 5500 Gb, а RAID6 а 5000Gb. Согласитесь, разница не принципиальная, зато надёжность на порядок выше. По поводу производительности, на большом массиве при преобладающих операциях чтения разница между 5 и 6 будет не столь существенной, в крайнем случае можно было бы установить дополнительный enclasure с дисками.
              0
              Это всё бесспорно. Но в любом случае без резервного копирования никуда. Скорее волнует, что диски из одной партии, и посыпаться могут вообще одновременно, там и 6 не спасёт. Это вечный спор, и решение принимается просто как баланс между противоречащими показателями. Мы решили, что 1 ТБ не лишний, и выигрышь в скорости, хоть может и не сильно заметный. Но, конечно, если когда-то умрёт 2 одновременно (тьфу-тьфу-тьфу), то мы пожалеем о принятом решении.
          +1
          последняя на данный момент версия — XenServer 6.1

          Последняя версия XenServer — 6.2.

          В семейство XenServer входит несколько версий продукта, отличающиеся ценой и дополнительными функциями.

          Начиная с 6.2 есть только одна версия, которая вобрала в себя все редакции.

          Web Self Service — начиная с 6.2 больше нет.

          Дальше возникает вопрос: где хранить виртуальные машины? Если их хранить на самих серверах, то это уменьшает надёжность системы, т.к. при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём

          Что вы будете делать если сдохнет полка с дисками?
          RAID-5 тоже странный выбор. Лучше уж RAID-6, если вам места жалко. Hot Spare-то есть?
            0
            Что вы будете делать если сдохнет полка с дисками?
            Hot Spare-то есть?

            Hot Spare на уровне дисков — да. На уровне самих серверов — нет. Нам не на сильно критично временное отключение 1-2 серверов. Нам важно, чтобы остальные при этом работали с теми же данными, которые были у всех.
            +2
            Как человек, три с половиной года, потративший на XenServer, могу сказать, что без очень серьёзной доработки напильником на низком уровне (то есть патчи на софт и скрипты) оно неработоспособно.

            Например, флуд-атака с rand-source на любую виртуалку парализует работу openvswitch и приводит к отказу management-сети. Антиспуфинг-скрипт глючный и не работает как надо на интерфейсах старше нулевого, миграция приводит к инкрементальным (нарастающим) утечкам памяти. Про «тонкости» работы с VHD даже говорить не приходится — там ад и ужас.
              +1
              1. Мы используем сервера исключительно для решения внутренних задач, поэтому нам не страшны флуд-атаки.
              2. Про VHD чистая правда, но приноровиться можно.
              +2
              >Первой задачей становится выбор основы для любого облака, а именно — выбор серверов
              А я думал, что первым делом пишут ТЗ. Для чего это облако? Как вы можете быть уверены, что выбрали верное решение если даже не поставили никакой задачи?
                0
                Во-первых не Fiber, а Fibre Channel.
                Во-вторых. WSS это не совсем замена XenCenter. Даже из его названия понятно на что он в первую очередь ориентирован, а именно — самообслуживание без участия админа облака. Т.е. самостоятельный реинсталл системы, перезагрузки и прочие базовые операции админами виртуалок. Т.е. с админа снимаются постоянные просьбы типа «виртуалка повисла на перезагрузке, просьба сделать force reboot». Но есть у него одна подлянка. Гипервизоры обычно сидят в сети управления без доступа во внешний мир, а эта зараза может работать только с гипервизорами напрямую — везде в интерфейсе жестко зашиты их адреса, т.е. даже проброс портов не поможет. Но есть сторонний бесплатный вариант без этих ограничений — xvp. Честно говоря мы его не пробовали, т.к. необходимость пропала.

                Ну и дальше по мелочи.
                Косяк с бубунтой лечится без консоли, просто используем network install и указываем урл.
                Плюс не совсем понял на фига использовали таких зверей, как 3850. Вместо четырех серваков лучше бы BaldeCenter взяли и набили их лезвиями в конфигурации типа Foundation for Cloud. И с дисками SSD, а то все брендовое железо и так любит долго стартовать, а тут хоть чуть-чуть время загрузки гипервизора сократите :)
                  0
                  Про WSS мы и пытались подчеркнуть эту же мысль, что он не позволяет решать многие админские задачи и очень ограничен в функциональности.

                  BladeCenter — хорошая штука. Сталкивались с модульными системами на примере Crossbeam — есть в этом свои особенности. Решили остановиться на отдельных серверах из-за большей гибкости.

                    0
                    Ну по поводу гибкости я бы поспорил. У вас всего 4 сервера, а заняли почти полностью весь шкаф. Хотя вы и так себе отрезали путь к расширению за счет отсутствия коммутатора FC. Дальше расширяться только с покупкой 1-2 коммутаторов. И в шкафу останется место еще под максимум 1 сервер.
                    С системами, подобными BC, вы бы те же вычслительные мощности уместили в половину шкафа и еще бы имели свободными корзины под 6-10 серверов.
                      0
                      Гибкость в возможности разделить на два отдельных кластера на разные площадки. Т.е. мы не привязаны к базе системы.
                        0
                        А коммутаторы и хранилище — пилить? :)
                          0
                          Нет )
                          Они же могут работать и как самостоятельные сервера. Жёсткие диски в них есть, так что в этом-то и идея, что при надобности их можно использовать отдельно.
                    0
                    Ох не сказал бы что HS22, что стоят в моем BCH, стартуют быстрее rack'овых серверов… Пока UEFI проинициализируется, FC, IB — проходит ого-го сколько времени :)
                      0
                      Я и не говорил, что лезвия шустрее обычных серверов стартуют. Они как любое брендовое железо — пока каждый болтик на плате не протестят, стартовать не начнут.
                      Скорость загрузки хоть немного может сократить SSD — гипервизор ощутимо быстрее стартует.
                    0
                    Не, с железом явно не подумали. Зачем оптику 10G кидать в пределах шкафа? Это же по SFP+ на каждый конец, плюс кабель. Дешевле кабели DAC — у них с каждого конца по SFP+, между ними медь, длина обычно 1,3 и 5 метров (вроде еще 10 бывают в природе).

                    Сервера напрямую в систему хранения включать? «Безумству храбрых.....». Вылетит один контроллер в системе хранения и досвидос половина облака пока замена не приедет. А дохнуть эти редиски любят значительно чаще коммутаторов, точнее говоря коммутаторов пока дохлых не встречал, а контроллеры менял неоднократно.
                      0
                      Из-за этой же экономии на коммутаторе уполовинили скорость каждому серваку — второй сосок в картах FC свободный висит… :(
                        0
                        А что мешает каждый сервер на два контроллера СХД повесить? У нас полка SAS, именно так и сделано. Т.е. на каждом серванте два SAS-HBA, каждый смотрит одним линком в отдельный контроллер СХД.
                          0
                          В данном случае мешает наличие всего 2 портов на каждом контроллере системы хранения. То есть их там суммарно по количеству серверов :(
                            0
                            Надо было брать полку SAS, скорость 6Gb, 4 входа на каждом контроллере, позволяет подключать 4 сервера с дублированием линков или 8 серверов без дублирования. Много раз встречал упоминания про SAS-коммутаторы, которые позволяют строить небольшие сети SAN на SAS, длина кабеля — 20 метров. Стоимость такого коммутатора от LSI — 2000$. Стоимость SAS-контроллера для полки раза в два дешевле, чем FC. FC в Вашем случае явно перебор.
                              0
                              Не в моем, а в случае автора статьи.
                              По поводу SAN на SAS подробно обсуждали в комментах здесь: habrahabr.ru/company/oblakoteka/blog/177047/
                              Я бы сказал, что это только для небольших систем. В случае крупной инфраструктуры цена FC уже не так принципиальна.
                              Но в случае топикстартера SAS HBA хватило бы за глаза.
                              0
                              У Вас серьёзный косяк с топологией. Если выходит из строя один СХД-контроллер, Вы теряете половину хостов Xen. Что будете делать в данной ситуации?
                                0
                                Я не автор статьи. Я собственно на тот же косяк автору указываю.
                          0
                          при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём. Также такой подход сильно усложняет задачу балансировки нагрузки, потому что миграция виртуальной машины потребует перемещения её диска на другой сервер, а это — достаточно долгий процесс. Поэтому в нашем стенде используется внешнее хранилище DELL md3620f

                          т.е. если у вас раньше ломался 1 сервер вы теряли половину машин и могли запустить резервные вм которые реплицровались на втором хосте, то сейчас если ломается DELL md3620f, вы наверно будете в шоколаде?

                          Или я не внимательно прочитал и у вас два хранилища с репликацией?
                            0
                            Всё правильно. Основная проблема у нас была именно с балансировкой нагрузки. Запускается одновременно много ВМ, и удобнее, если они все хранятся в едином месте, чтобы не перемещать и их между локальными дисками серверов.

                            В той схеме которая у нас реализована, узким местом является именно хранилище. Сейчас есть RAID для защиты от выхода из строя дисков. Защита от выхода из строя хранилища решается через репликацию, но нужно ещё хранилище. Со временем придём к этому, а вместе с этим перейдём и на оптический коммутатор.
                            0
                            А можно узнать ценник? Т.е. можно собрать подобное облако «на коленке», используя платформы от Intel и хранилища от Supermicro, такой подход будет иметь много минусов, но одним из плюсов будет цена. Используя вендорное железо, мы получаем плюсы в поддержке и некой ментальной надежности (да и вообще, это же «ынтырпрайз»), но ценник будет совершенно иным. Собственно и интересно — сколько в конечном счете стоит такая стоечка (если можно, то с детализацией)?
                              0
                              Сложно сейчас сказать. Покупалось последовательными группами, поэтому сейчас тяжело всё вспомнить, но на вскидку 7-8 млн.
                              0
                              Думаю, при виде этой цифры многие матерят своё «место работы» :)

                              Но все равно без второго хранилища я бы не рискнул бы что-то делать в рабочей среде.
                              Слышал случаи когда ломалась единственная схд, слесари использовали попку админа как пневмо-кусачки для перекусывания ломиков!

                              Кто лично знает такие истории отзовитесь ;)
                                0
                                А как именно может сломаться целая полка, там ведь нет единой точки отказа? Два контроллера, т.е. должны сломаться сразу оба? Ну тогда сразу могут сломаться и обе полки. Или речь о программной сбое?
                                  0
                                  Да запитает электрик две розетки от разных фаз и все дела… (случай из личного опыта)

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

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