Как мы заново собирали серверы в американском ЦОДе из России

    Сегодня мы хотели рассказать вам о том, как наши ребята за три часа повысили производительность кластера для тестирования ПО в 4 раза, просто «пораскинув мозгами».

    image

    Upd. Этот пост это — НЕ МАСШТАБНОЕ ТЕСТИРОВАНИЕ — это реальная история из практики с забавными моментами. Мы повысили плотность ВМок в 4 раза, если вы ожидаете увидеть сравнительное тестирование, графики и анализ производительности, вам не сюда. Тут сегодня скорее душевное чтиво.

    Сделаем несколько ремарок, чтобы было понятно, откуда у нашей темы «ноги растут». Особенность работы Virtuozzo состоит в том, что отдел разработки и все программисты находятся в Москве (наследие SWsoft и нашей альма-матер, ФизТеха), а головной офис – в Сиэтле (США). Но для сегодняшнего поста это важно лишь потому, что наш HPC-кластер для тестирования ПО находится также в США, а основные «заказчики» тестовых задач – в Москве. И несмотря на весь удаленный доступ, это могло бы быть проблемой, ведь между этими двумя точками – 11 часовых поясов, и когда рабочий день начинается в Сиэтле, он заканчивается в Москве, а значит поменять что-то на серверах физически — непросто.

    image

    Запустили, но не заточили


    Но давайте предметно: чтобы тестировать новые версии ПО Virtuozzo был запущен большой кластер из 10 машин, на котором мы установили нашу систему виртуализации, а на уровне ВМ – снова загружаем наш софт для многочисленных тестовых прогонов. Несмотря на постоянный мониторинг этого процесса со стороны инженеров-разработчиков, более 99% нагрузки на кластер создают автоматизированные боты, которые стремятся запустить как можно больше подзадач тестирования в каждый момент времени.

    Кластер был запущен относительно недавно, и на площадке ЦОД, где мы арендуем место, нет постоянного персонал Virtuozzo. И вроде бы это не должно быть проблемой – все же можно сделать удаленно… ну кроме физического реконфигурирования, а именно в нем и возникла потребность у наших ребят, так как у нас получалось запускать только 5-7 вложенных ВМ, когда хотелось намного больше.

    Оказалось, что 10 серверов с процессорами Xeon L5640 и Xeon X5650 могут взять на себя достаточно высокую нагрузку, даже с учетом того, что на них работает система хранения данных Virtuozzo Storage. Но вот распределение памяти и дисков между ними было проведено без учета предстоящих задач, а установленные дополнительные сетевые карты не могли обеспечить прирост производительности, так как стояли просто «не там, где нужно».

    image

    Проанализировав кластер, мы поняли, что зря не составили предварительную модель работы при его сборке, потому что:

    1. Трафик доступа к ВМ пользователей (в основном ботов) перемешивался с трафиком системы хранения, забивая канал
    2. Виртуальные машины бессмысленно запускались на нодах с малым объемом ОЗУ, перегружая их
    3. Дополнительные сетевые карты просто простаивали из-за отсутствия правил перераспределения трафика

    Чтобы победить все это безобразие, было решено пересобрать ряд серверов по следующим правилам:

    — Установить по 2 (или 4 для серверов с VZ Storage) сетевые карты во всех серверах
    — В серверы с менее мощными процессорами вставить самые емкие диски и объединить дополнительные сетевые интерфейсы (для VZ Storage) в бонды
    — В серверы с более мощными процессорами вставить менее емкие диски, но максимум ОЗУ.

    От Брайтон бич до Дерибасовской


    Чтобы провести эту «рокировку», нужен был «свой человек» в Сиэтле, и им стал наш коллега Кирилл Колышкин. Он по счастью имел доступ в ЦОД, и, хотя не являлся администратором кластера, был рад нам помочь.

    Мы засели в конце рабочего дня с полной готовностью к работе, но Кирилл застрял в пробке и добрался к ЦОДу только в 20-30 по Москве. Пятница вечер, хочется домой, но работать надо. И мы начинаем в общем чате обсуждать, что и куда нужно установить.

    «Я откуда знаю, как? Я в данном случае выполняю роль железного инженера, я в ваших системах ничего не понимаю», — одна из самых важных фраз нашего инженера.

    Да, он работал вслепую и по указке, поэтому у нас было несколько очень интересных моментов. Чтобы не портить ощущение от процесса, приведем просто выдержки бесед из чата, в котором варилась вся каша:

    kir [9:15 PM] я уронил пару болтиков, хотел у кого-нибудь спросить, где их можно тут найти
    [9:15] ладно, сам поищу
    [9:30] продолжаю искать болтики
    [9:40] фиг с ними, с болтиками

    [9:19] парни, я ударился головой об сервер
    [9:19] пойду остановлю кровь
    [9:19] (это не шутка)

    Параллельно мы узнали много нового о наших системах, которые спокойно стоят в США:

    kir [9:51 PM] У машины 118 гнутый рейлинг справа, чуть на ногу мне не упал, еле поставил обратно
    apershin [9:52 PM] там на входе каски не выдавали ?)) как на опасных производствах )))
    kir [9:52 PM] он там по сути на одной половине висит, точнее лежит на предыдущем

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

    Alexandr: американцы — опять эти безумные русские хакеры что-то тут затевают — наверняка атаку на штаб Хилари ))))
    apershin [11:05 PM] Ща мы допишемся, там за Киром приедут )))

    Кирилл, конечно, очень хотел уже уйти из серверной и перестать заниматься делами, которые к нему фактически никак не относятся:

    [11:41] Я готов отсюда отчаливать
    [11:42] скажи мне, когда можно будет
    [11:42] А то время обеда уже давно прошло
    [11:45] Дяденька, а дяденька
    [1:11] же не манж па сис жюр


    image
    «kir [10:47] короче все винты у меня на тележке»

    Несколько часов и результат

    Но отпустить Кирилла слишком рано мы не могли, потому что не все сразу заработало. Оказалось, что у нас больше сетевых карт, чем мы думали, оказалось, что не все кабели работали хорошо и, наконец, выяснилось, что на серверах имеются разные настройки BIOS, и некоторые из них просто не стали перезапускаться после смены конфигурации.

    Мы проверяли линки, меняли патч-корды, заново ставили систему, и в результате ближе к часу ночи по Москве отпустили Кирилла с ушибленной ногой, поврежденной головой и голодным желудком разбираться со своими рабочими вопросами (обед-то он уже пропустил, так что отделался легким перекусом).

    Что мы получили в итоге – так это более производительный кластер для тестирования: вместо 5-7 виртуалок в каждом окружении мы смогли запускать 15-20 штук. При этом Storage работал на отдельной сети через выделенный коммутатор, не мешая запросам ботов и пользователей. Так, наша команда доказала свою сплочённость, а серверы стали работать куда эффективнее за счет оптимального распределения компонентов. Так что не бойтесь удаленной работы с серверами – главное, чтобы на месте был надежный человек, который не боится ни травм, ни голода.
    Virtuozzo 60,19
    Разработчик ПО для контейнерной виртуализации
    Поделиться публикацией
    Комментарии 23
    • +5
      мы хотели рассказать вам о том, как наши ребята за три часа повысили производительность кластера для тестирования ПО в 4 раза, просто «пораскинув мозгами»


      Трафик доступа к ВМ пользователей (в основном ботов) перемешивался с трафиком системы хранения, забивая канал
      Виртуальные машины бессмысленно запускались на нодах с малым объемом ОЗУ, перегружая их
      Дополнительные сетевые карты просто простаивали из-за отсутствия правил перераспределения трафика


      Вот видите, хотели рассказать об одном, а рассказали о другом — как ваши ребята позабыли (?) про то, что планирование обычно делают до инсталляции, а не после, после чего в лучших традициях героически преодолели… :)
      • 0
        С одной стороны вы совершенно правы, ildarz. Но дело в том, что серверы ставили в США, а пользователи в России. А во-вторых профили нагрузки заранее были не известны. Нет, конечно, лучше было бы все сделать сразу и хорошо… но у вас часто так бывает? :)
        • +3
          Скажем так — допускаю, что проблема 2 действительно могла проявиться только в процессе эксплуатации, но 1 и 3 — совершенно чётко детские ошибки планирования. Оправдать это можно только в одном случае — если делали в первый раз (нет опыта) и в большой спешке (не было времени, чтобы хотя бы поверхностно ознакомиться с предметной областью). Если у ваших ребят нет привычки много раз наступать на одни и те же грабли, то ничего страшного, но я бы на месте их руководителя убедился, что урок усвоен правильно. :)
          • 0
            Мы компания молодая (с января в таком виде работаем), так что да — неслаженность процессов имела место быть. Сами посмотрели, на ус намотали, если кому-то поможет избежать подобных ситуаций, будет очень хорошо!
      • 0
        «дорогой дневничок! сегодня мы из одних серверов доставали железочки и вставляли в другие!»
        совершенно никакой полезной информации не вижу в этом посте, к сожалению. ни метрик, ни тестов, ни конфигов — ничего.
        хабр не торт :(
        • 0
          dvsx86, вы слишком часто читаете девчачьи дневнички, раз такие ассоциации. )))
          Мы уплотнили количество ВМок вдвое. Пришли к выводу, что при группировке стораджа на отдельные интерфейсы, производительность при тестовых прогонах выросла в разы (при интенсивных нагрузках тестирования ПО). Если вам эта информация не интересна, проходите дальше, не претендуем на авторитетное тестирование и сравнение — это случай из жизни нормальных тестировщиков, вынужденных работать на железе, к которому нет физического доступа.
          И да, хабр — не торт. Никто не сомневался. :)
          • –1
            Очень смешно! Сначала пишите, что уплотнили в 4 раза, потом — вдвое. Почему в 10 раз не написать?! Лажа…
            • 0
              А вы, видимо, не умеете читать. Я специально для таких написал еще до ката, что текст не претендует на аналитику или точное исследование. Никто в этом посте не пытался показать достижения или эффективность каких-то продуктов. Это сторителлинг про удаленную модернизацию руками практически постороннего человека. Плотность вложенных ВМ-ок была 5-7, а на выходе получилось до 20 — отсюда и характеристика примерно в 4 раза. Так что сам вы лажа, уважаемый! :)
        • +1
          А вы с Киром после этого общались или может за ним таки «пришли»?
          • 0
            Не, с Киром все нормально. Может конечно и «пришли», но он из ЦОДа уже успешно ушел и даже после этого выходил на связь… правда в Telegram по шифрованному каналу. :)
          • +2
            Что то я так и не понял — о чём статья? Как имея в продуктивной среде вы начали перепланировать и по-максимуму переделывать то, что было изначально плохо спланировано и получили прирост? Ну круто… у нас большая часть страны так живёт и не только в IT :)
            • 0
              Не по максимуму, а «там где надо», и что спланировано было недостаточно — выяснилось в процессе эксплуатации, когда подсистема хранения стала давать очень большие нагрузки на сеть. Но в целом, да, вы правы. Пример успешного решения классической задачи повышения эффективности, но с трансокеанскими переменными. И текст, не о том, что перепланировали, а о том, что успешно решили задачу за несколько часов, по удаленке и сами себе доказали, что выделение стораджа в отдельный сегмент сети на отдельных сетевых карточках дал серьезный рост производительности в целом. Для нас была ценная находка, если вам и так очевидно, то слава богу!
            • +1
              Занимательное чтиво, но из него я понял, что вы дважды не сумели спланировать действия. В первый раз при инсталляции кластера (спишем на то, что «Мы компания молодая»). И второй раз, когда планировали изменение конфигурации. Провести инфентаризацию сетевых карт точно можно было заранее.
              Я бы постеснялся выкладывать такую историю.
              P.S.: Сам по работе бываю удалёнными руками и у меня бывают удалённые руки.
              • 0
                Да, конечно, вы правы. Многое можно было сделать лучше — и сейчас это понятно. Но у нас был такой первый опыт, и захотелось им поделиться. Может кому-то удастся учиться на наших ошибках, мы же поучились на своих. Все вышло благополучно, результат достигнут… ну а доказывать, что мы супер все подготовили и спланировали цели не было. Можно было запланировать, сделать заявку в штаты, разработать план, привлечь кучу людей, потратить на это кучу денег и ресурсов… но вышел такой опыт — может кому-то кажется полезен.
              • +1
                Автору — спасибо за статью. Некоторым комментаторам — не наваливайтесь особо на молодые команды. Они публикуются, может и для того, чтобы почувствовать свою принадлежность к командам настоящих спецов, чтобы стать, такими как Вы, ассами. Не у всех получится, однако пусть пытаются, пусть пробуют. Сами, что-ли никогда не ошибались. Команда еще молодая. Успехов ей
                • 0
                  +1
                  • 0
                    Команда молодая? Это все те же ребята, которые работали еще в SWsoft.
                    • 0
                      Сергей, ну как экс-сотрудник вы прекрасно знаете, что молодые в данном случае процессы. Компания работает в текущем виде не так долго, в результате много что не согласовано и не отлажено. И еще раз повторюсь — поделились опытом, может кому полезно будет — не пытаемся похвастаться чем-то
                  • +1
                    Любая история чему-то учит, чему учит эта можно вообще обсуждать в отдельной статье… Мне больше интересно следующее: а товарищ этот американский(Кирилл), он там всю дорогу в одиночку работал или все-таки дружина у него все-таки была?

                    • 0
                      Нет, он был совершенно один — все делал сам по «руководству» через slack
                    • 0
                      Лучше бы вы написали, что эти все эти сервера пожертвовала компания Atlassian проекту OpenVZ. А сейчас на них тестируется проприетарная файловая система Virtuozzo Storage.
                      • 0
                        Ну может и лучше бы… но опять же все не совсем так — VZ Storage обслуживает как хранилище те тестовые задачи, которые запускаются на серверах. А это как раз OpenVZ. :) Но исходный код у VZ и OpenVZ сейчас развивается параллельно, так что эти задачи сложно отделить друг от друга.

                        Сергей, у вас зуб на компанию после ухода? Так бывает. Но ваши бывшие коллеги просто захотели рассказать о своем опыте, мне кажется, не нужно здесь выливать свое недовольство.
                        • 0
                          > Ну может и лучше бы… но опять же все не совсем так — VZ Storage обслуживает как хранилище
                          > те тестовые задачи, которые запускаются на серверах. А это как раз OpenVZ. :)
                          > Но исходный код у VZ и OpenVZ сейчас развивается параллельно, так что эти задачи сложно
                          > отделить друг от друга.

                          Задачи отделить вполне можно, так же как и резделить ресурсы открытого проекта и ресурсы коммерческой компании. Но Virtuozzo это не делает, потому что с выбранной моделью разработки можно спекулировать термином «открытый проект» и пользоваться ресурсами OpenVZ закрывая дыры в бюджете компании. :)

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

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

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