Почему PayPal заменил VMware OpenStack-ом?



    Почти 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 физических серверах. И это далеко не предел — новости в этой сфере еще впереди.
    King Servers
    Хостинг-провайдер «King Servers»
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 14

      +4
      PayPal заменил арендуемый у eBay VMWare на свой персональный OpenStack. Почему бы?)
        0
        А как CMP, то есть система управления облаком, может заменить базовую виртуализацию, то есть VMware vSphere, в данном случае? «Внизу» всегда есть гипервизор. А вот произошёл ли переезд на новый гипервизор не указано.
          +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, а для многих это и не возможно по причине закрытых сырцов.
            0
            Разница между гипервизорами например в производительнсти IO.
              +4
              Зачастую это разница оборудования.
                +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 «от» и «до»), ещё один важный бонус.
                  0
                  > При использовании паравиртуализованных драйверов вопросы гонки производительности уже давно ушли в район десятков гигабит (и немного отстают от производительности хоста).
                  Подскажите, пожалуйста, что нужно сделать с VMware, чтобы она без использования SR-IOV или проброса сетевой карты в гостевую систему выдавала бы более 3 Гбит/с? В случае SR-IOV или VMDirectPath все 10 Гбит/с доступны, а через виртуальный свитч и виртуальные сетевые карты vmxnet3 больше 3-4 Гбит/с получить не получалось.
                    0
                    Развожу руками, ибо я только с xen работал (в прошлом) и теперь с KVM. По тому, что я слышал про VMWare, 10G она в виртуалках (без SR-IOV) выдаёт. Из интуитивного — попоробовать сетевуху, в которой прерывания могут по нескольким процессорам размазываться (ixgbe умеет, ixgb умеет, e1000e — не умеет).

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

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

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

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

              Only users with full accounts can post comments. Log in, please.