Почти 100% трафика, идущего через PayPal и API сервиса, включая сервисы-посредники, сейчас обслуживается частным облаком OpenStack, которым владеет сама компания.

OpenStack заменил VMware в принадлежащих eBay дата-центрах, через которые проходят платежи. Преобразования шли поэтапно, а началось все во время шоппинг-сезона 2011 года, когда инфраструктурная команда PayPal решила перевести около 20% трафика компании на облако OpenStack.

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

«С OpenStack наша компания может самостоятельно держать под контролем кастомизацию своего ПО, у нас сейчас большой выбор поставщиков гибридного облачного окружения», — прокомментировал Шри Шивананда, вице-президент инфраструктурного подразделения PayPal. Он также сообщил, что у компании сейчас уходят минуты на развертывание новых Java-приложений — это необходимо для того, чтобы идти в ногу со временем и потребностями потребителей.

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



Стоит отметить, что VMware и OpenStack не взаимоисключают друг друга. Так, телекоммуникационный гигант из Пало Альто, Калифорния, получил собственную версию OpenStack, интегрированную со своим гипервизором и другими инфраструктурными решениями ДЦ. VMware Integrated OpenStack поставляется с последним пакетом vSphere 6.

«Цель такой интеграции — предоставление клиентам возможности усилить действенность собственных инвестиций, с получением OpenStack и объединенной поддержки от VMware», — прокомментировал ситуацию Роджер Фортьер, пресс-секретарь VMware.

В настоящее время все большее количество компаний обращают внимание на OpenStack. В числе прочих можно назвать таких гигантов, как Walmart Labs, Time Warner Cable, и CERN (оператор Большого Адронного Коллайдера". В ноябре прошлого года CERN увеличил размер облака OpenStack на 1500000 процессорных ядер. Активно работает с облаком OpenStack и BMW, пока что концерн просто тестирует возможность работы с новым для себя инфраструктурным решением.

Недавний опрос среди ИТ-специалистов показал, что около трети всех пользователей облачных сервисов имеют собственные частные облака. И половина из них работает на основе OpenStack.

Положительным моментом является и то, что облачное open-source программное обеспечение открыло возможность для сервис-провайдеров создавать открытые облака. К примеру, у Rackspace одн из наибольших OpenStack-облаков. Другой пример — Internap, запустивший собственные облачные сервисы на основе OpenStack ранее в этом году.

Покупательский трафик такого гиганта, как Walmart также обслуживает OpenStack. Rackspace при этом помог команде Walmart Labs построить облачную инфраструктуру. Теперь Walmart работает с версией OpenStack инфраструктуры от RackSpace.

Производители проприетарного оборудования и ПО, видя все растущую популярность OpenStack, поневоле начинают интегрировать новые решения в собственную инфраструктуру, предлагая обновленные проекты и сервисы. В противном случае такие производители вполне могли бы потерять часть рынка.



Тем не менее, попадаются и компании, вроде PayPal, которые могут создавать собственную облачную инфраструктуру на основе OpenStack, для себя самих. Сейчас объедиенная инфраструктура PayPal и eBay базируется на 8500 физических серверах. И это далеко не предел — новости в этой сфере еще впереди.

Комментарии (14)


  1. Louter
    17.04.2015 21:46
    +4

    PayPal заменил арендуемый у eBay VMWare на свой персональный OpenStack. Почему бы?)


  1. ZloyKakPes
    17.04.2015 22:25

    А как CMP, то есть система управления облаком, может заменить базовую виртуализацию, то есть VMware vSphere, в данном случае? «Внизу» всегда есть гипервизор. А вот произошёл ли переезд на новый гипервизор не указано.


    1. amarao
      17.04.2015 22:53
      +14

      А это и не важно. Внезапно, «они все одинаковые». При том, что очень крутой эксперт сможет потыкать пальцем в различия между Xen'ом, KVM'ом, VMWare и Hyper-V, но они все очень долго и упорно работали на то, чтобы быть неотличимыми с практической точки зрения пользователя, который логинится в виртуалку и запускает там свой код.

      Они различаются (радикально) со стороны «back-office». То, как это видит админ, и это то, на что обычно показывают, говоря про различия гипервизоров. Всем очевидно, что KVM и Hyper-V — это фантастическая разница, разные школы администрирования, разные тулстеки, разные ОС. Всё разное. Педанты смогут сказать, что Xen и EXSi — это первого типа, а KVM и Hyper-V — второго.

      Однако, openstack энкапсулирует гипервизоры абстракциями более высокого уровня. Ровно так же, как с точки зрения автора программ, чаще всего нет никакой разницы между Intel'ом и AMD — «оно просто работает». Бывают edge-case'ы, когда это важно, но большей частью — совсем-совсем пофигу.

      Openstack — это унифицированные ручки для управления инфраструктурой. В условиях, когда гипервизоры отлажены до совершенства, именно эти ручки оказываются критическими. В существующем IT каждый болтик не должен быть произведением искусства и иметь совершенные размеры. Он должен иметь такие размеры, чтобы хорошо закручиваться с гайкой. А если не закручивается, то никого не волнует икрустация по краю шляпки. Если закручивается — ну, можно полюбоваться и поспорить чья школа лучше.

      В Openstack одинаково хорошо (я верю в вас, ребята из Microsoft) вкручивается и Hyper-V, и VMWare, и KVM. И они начинают работать как примитивные болтики. Никого не волнует мнение гипервизора о высокой политике (аллокации ресурсов или скедулинга), дело гипервизора — гипервизорить. А вся важная логика (скедулинг, управление снапштами, правами доступа, настройками сети) — это openstack, который стандартен.

      И не только стандартен, но и очень ковырябелен. Практически все люди, которые юзают опенстек всерьёз, так или иначе его под себя патчили. Одному важно одно, другому — другое.

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


      1. boblenin
        18.04.2015 04:16

        Разница между гипервизорами например в производительнсти IO.


        1. bioskiller
          18.04.2015 04:43
          +4

          Зачастую это разница оборудования.


        1. amarao
          18.04.2015 15:12
          +8

          Разница между гипервизорами в производительности в оптимальных настройках гостей несущественна. В реальной жизни её:

          а) не обнаружить из-за того, что девиация производительности железа больше разницы между производительностью гипервизоров (всякие turbo boost'ы и т.д.)
          б) не обнаружить из-за того, что реальные ОС (применяемые в продакшене) не realtime и могут заняться более важными процессами, чем тест, в процессе тестирования.

          По CPU производительность у всех давно за 99% зашкалила. По IO — надо смотреть на технологию виртуализации оборудования (которая к гипервизору постольку поскольку). При SR-IOV производительность будет одинаковая у любого гипервизора. При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).

          А вот COW-формат диска или RAW (самый острый вопрос, где IO может в 2-3 раза падать по сравнению с baremetall) — это решение администратора. Хочет плюшек? COW. Хочет производительности? RAW. Все гипервизоры умеют и то, и то.

          На практике «производительность гипервизоров» мгновенно заслоняется более важными вещами: «нет, ЭТО сделать нельзя, потому что в модели тулстека Х предполагается, что ...», или «по архитектурным соображениям ограничение в тулстеке на число сетевых интерфейсов — 15».

          Заметим, это каждый раз ограничения тулстека, а не гипервизора. Иногда ограничения идиотские, иногда осмысленные. Но чтобы об этом особо не думает, и существует openstack с унифицированным подходом. Ярче всего его видно на примере интеграции xenserver в openstack.

          Каждый хост xenserver является пулом. Никаких «пулов на несколько серверов». Никого не интересуют интимные взаимоотношения двух хостов в пуле и выяснения кто из них мастер.
          Каждый диск делается в своём SR'е. Никаких «base copy», интимных взаимоотношений с драйвером SR, выясняющим где чьи данные и кто от кого произошёл. Никаких thin copy, с последующим мучением «ограничение на длинну цепочки», «мультипликация IO на запись» и т.д. Выдали файл образа — запусти с него виртуалку. Надо сделать снапшот? Выдай полную копию. Всё.

          Вот эта грубоватая простота — она очень приятна. И получающаяся мультитенантность (никто, кроме openstack не даёт настоящего multitenancy «от» и «до»), ещё один важный бонус.


          1. phprus
            18.04.2015 16:20

            > При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).
            Подскажите, пожалуйста, что нужно сделать с VMware, чтобы она без использования SR-IOV или проброса сетевой карты в гостевую систему выдавала бы более 3 Гбит/с? В случае SR-IOV или VMDirectPath все 10 Гбит/с доступны, а через виртуальный свитч и виртуальные сетевые карты vmxnet3 больше 3-4 Гбит/с получить не получалось.


            1. amarao
              18.04.2015 16:38

              Развожу руками, ибо я только с xen работал (в прошлом) и теперь с KVM. По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт. Из интуитивного — попоробовать сетевуху, в которой прерывания могут по нескольким процессорам размазываться (ixgbe умеет, ixgb умеет, e1000e — не умеет).

              В контексте openvswitch я видел 8Гбит. Рассказывают, что (без dpdk) оно умеет выдавать до 20Гбит на новой версии (руки не дошли побенчмаркать) с хорошим железом.


              1. phprus
                18.04.2015 16:47

                В серверах у меня физически карточки от Mellanox стоят.
                Если брать KVM + SR-IOV, то до 20 Гбит/с оно выдает. С виртуальными сетевыми картами я правда не пробовал такую конфигурацию тестировать. А в VMware SR-IOV у меня нет, так как оно только в самой дорогой подписке доступно :)

                > По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт.
                Эх, знать бы какие ручки для этого нужно подкрутить.


                1. ZloyKakPes
                  20.04.2015 09:04

                  Развожу руками, ибо я только с xen работал (в прошлом) и теперь с KVM.
                  Уважаемый amarao, я перепробовал и поработал на проэктах с Xen, Hyper-V (начиная с первой версии) и vSphere (с 3.5). Коллеги, мнению которых я доверяю, сталкивались с Oracle VM.
                  Так вот, внезапно гипервизоры далеко не одинаковые, не были, не есть, и в ближайшие годы точно не будут. Во-вторых, vCloud Director даёт тру multitenancy, Virtual Machine Manager был почти true в 2012.
                  phprus, а по поводу производительности виртуалки — пишите в личку, обсудим.


  1. Bytamine
    17.04.2015 23:48
    +10

    > Компания самостоятельно построила облако OpenStack. При этом у PayPal был выбор: создать облако самостоятельно, или нанять специалиста или даже компанию, которые смогли бы внедрить собственные решения для PayPal. Компания выбрала самостоятельный путь, и сейчас руководство нисколько не жалеет об этом.

    Специалисты из компании Мирантис, если они тут появятся, могут рассказать, насколько самостоятельно PayPal это сделал )


    1. 121212121
      19.04.2015 11:17

      Мешает какая то подпись, по слухам.


  1. antonvn
    19.04.2015 21:17

    Не секрет, что лицензия на vSphere стоит сильно дороже самого железа, на котором оно работает. При этом для обслуживания небольшой инсталляции до Х хостов достаточно небольшого числа специалистов определенной квалификации, при том что в VMware почти всё делается сравнительно просто и мышкой в GUI. С другой стороны, запуск аналогичного решения на OpenStack потребует совсем другого штата людей для ковыряния консоли, скриптописательства и прочих нетривиальных вещей. При росте Х наверняка есть какая-то критическая точка, при которой выгоднее становится содержать собственную толпу админов-линуксоидов на развитии и поддержке (это если делать на KVM), чем продолжать кормить VMware Inc за каждый следующий физический процессор. Моя личная оценка Х — порядка 50.
    Может я отстал от жизни, но есть ли в KVM/Openstack функционал, схожий с CBT, DRS, интегрированные бэкапы типа вима, нормальная поддержка общих блочных хранилищ и плагины к ним?


    1. Equin0x
      21.04.2015 03:51

      Судя по наблюдаемому всплеску вакансий в области KVM+Puppet/Chef — к этому выводу приходят и компании помельче.

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