Upd. Этот пост это — НЕ МАСШТАБНОЕ ТЕСТИРОВАНИЕ — это реальная история из практики с забавными моментами. Мы повысили плотность ВМок в 4 раза, если вы ожидаете увидеть сравнительное тестирование, графики и анализ производительности, вам не сюда. Тут сегодня скорее душевное чтиво.
Сделаем несколько ремарок, чтобы было понятно, откуда у нашей темы «ноги растут». Особенность работы Virtuozzo состоит в том, что отдел разработки и все программисты находятся в Москве (наследие SWsoft и нашей альма-матер, ФизТеха), а головной офис – в Сиэтле (США). Но для сегодняшнего поста это важно лишь потому, что наш HPC-кластер для тестирования ПО находится также в США, а основные «заказчики» тестовых задач – в Москве. И не смотря на весь удаленный доступ, это могло бы быть проблемой, ведь между этими двумя точками – 11 часовых поясов, и когда рабочий день начинается в Сиэтле, он заканчивается в Москве, а значит поменять что-то на серверах физически — непросто.
Запустили, но не заточили
Но давайте предметно: чтобы тестировать новые версии ПО Virtuozzo был запущен большой кластер из 10 машин, на котором мы установили нашу систему виртуализации, а на уровне ВМ – снова загружаем наш софт для многочисленных тестовых прогонов. Несмотря на постоянный мониторинг этого процесса со стороны инженеров-разработчиков, более 99% нагрузки на кластер создают автоматизированные боты, которые стремятся запустить как можно больше подзадач тестирования в каждый момент времени.
Кластер был запущен относительно недавно, и на площадке ЦОД, где мы арендуем место, нет постоянного персонал Virtuozzo. И вроде бы это не должно быть проблемой – все же можно сделать удаленно… ну кроме физического реконфигурирования, а именно в нем и возникла потребность у наших ребят, так как у нас получалось запускать только 5-7 вложенных ВМ, когда хотелось намного больше.
Оказалось, что 10 серверов с процессорами Xeon L5640 и Xeon X5650 могут взять на себя достаточно высокую нагрузку, даже с учетом того, что на них работает система хранения данных Virtuozzo Storage. Но вот распределение памяти и дисков между ними было проведено без учета предстоящих задач, а установленные дополнительные сетевые карты не могли обеспечить прирост производительности, так как стояли просто «не там, где нужно».
Проанализировав кластер, мы поняли, что зря не составили предварительную модель работы при его сборке, потому что:
- Трафик доступа к ВМ пользователей (в основном ботов) перемешивался с трафиком системы хранения, забивая канал
- Виртуальные машины бессмысленно запускались на нодах с малым объемом ОЗУ, перегружая их
- Дополнительные сетевые карты просто простаивали из-за отсутствия правил перераспределения трафика
Чтобы победить все это безобразие, было решено пересобрать ряд серверов по следующим правилам:
— Установить по 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] же не манж па сис жюр
«kir [10:47] короче все винты у меня на тележке»
Несколько часов и результат
Но отпустить Кирилла слишком рано мы не могли, потому что не все сразу заработало. Оказалось, что у нас больше сетевых карт, чем мы думали, оказалось, что не все кабели работали хорошо и, наконец, выяснилось, что на серверах имеются разные настройки BIOS, и некоторые из них просто не стали перезапускаться после смены конфигурации.
Мы проверяли линки, меняли патч-корды, заново ставили систему, и в результате ближе к часу ночи по Москве отпустили Кирилла с ушибленной ногой, поврежденной головой и голодным желудком разбираться со своими рабочими вопросами (обед-то он уже пропустил, так что отделался легким перекусом).
Что мы получили в итоге – так это более производительный кластер для тестирования: вместо 5-7 виртуалок в каждом окружении мы смогли запускать 15-20 штук. При этом Storage работал на отдельной сети через выделенный коммутатор, не мешая запросам ботов и пользователей. Так, наша команда доказала свою сплочённость, а серверы стали работать куда эффективнее за счет оптимального распределения компонентов. Так что не бойтесь удаленной работы с серверами – главное, чтобы на месте был надежный человек, который не боится ни травм, ни голода.
Комментарии (18)
dvsx86
21.11.2016 13:52«дорогой дневничок! сегодня мы из одних серверов доставали железочки и вставляли в другие!»
совершенно никакой полезной информации не вижу в этом посте, к сожалению. ни метрик, ни тестов, ни конфигов — ничего.
хабр не торт :(
Gummio_7
21.11.2016 13:58dvsx86, вы слишком часто читаете девчачьи дневнички, раз такие ассоциации. )))
Мы уплотнили количество ВМок вдвое. Пришли к выводу, что при группировке стораджа на отдельные интерфейсы, производительность при тестовых прогонах выросла в разы (при интенсивных нагрузках тестирования ПО). Если вам эта информация не интересна, проходите дальше, не претендуем на авторитетное тестирование и сравнение — это случай из жизни нормальных тестировщиков, вынужденных работать на железе, к которому нет физического доступа.
И да, хабр — не торт. Никто не сомневался. :)iPumbaza
22.11.2016 19:13-1Очень смешно! Сначала пишите, что уплотнили в 4 раза, потом — вдвое. Почему в 10 раз не написать?! Лажа…
Gummio_7
22.11.2016 19:16А вы, видимо, не умеете читать. Я специально для таких написал еще до ката, что текст не претендует на аналитику или точное исследование. Никто в этом посте не пытался показать достижения или эффективность каких-то продуктов. Это сторителлинг про удаленную модернизацию руками практически постороннего человека. Плотность вложенных ВМ-ок была 5-7, а на выходе получилось до 20 — отсюда и характеристика примерно в 4 раза. Так что сам вы лажа, уважаемый! :)
KorP
21.11.2016 18:17+2Что то я так и не понял — о чём статья? Как имея в продуктивной среде вы начали перепланировать и по-максимуму переделывать то, что было изначально плохо спланировано и получили прирост? Ну круто… у нас большая часть страны так живёт и не только в IT :)
Gummio_7
21.11.2016 18:45Не по максимуму, а «там где надо», и что спланировано было недостаточно — выяснилось в процессе эксплуатации, когда подсистема хранения стала давать очень большие нагрузки на сеть. Но в целом, да, вы правы. Пример успешного решения классической задачи повышения эффективности, но с трансокеанскими переменными. И текст, не о том, что перепланировали, а о том, что успешно решили задачу за несколько часов, по удаленке и сами себе доказали, что выделение стораджа в отдельный сегмент сети на отдельных сетевых карточках дал серьезный рост производительности в целом. Для нас была ценная находка, если вам и так очевидно, то слава богу!
Tomatos
21.11.2016 21:54+1Занимательное чтиво, но из него я понял, что вы дважды не сумели спланировать действия. В первый раз при инсталляции кластера (спишем на то, что «Мы компания молодая»). И второй раз, когда планировали изменение конфигурации. Провести инфентаризацию сетевых карт точно можно было заранее.
Я бы постеснялся выкладывать такую историю.
P.S.: Сам по работе бываю удалёнными руками и у меня бывают удалённые руки.Gummio_7
21.11.2016 22:39Да, конечно, вы правы. Многое можно было сделать лучше — и сейчас это понятно. Но у нас был такой первый опыт, и захотелось им поделиться. Может кому-то удастся учиться на наших ошибках, мы же поучились на своих. Все вышло благополучно, результат достигнут… ну а доказывать, что мы супер все подготовили и спланировали цели не было. Можно было запланировать, сделать заявку в штаты, разработать план, привлечь кучу людей, потратить на это кучу денег и ресурсов… но вышел такой опыт — может кому-то кажется полезен.
georgevp
22.11.2016 01:09+1Автору — спасибо за статью. Некоторым комментаторам — не наваливайтесь особо на молодые команды. Они публикуются, может и для того, чтобы почувствовать свою принадлежность к командам настоящих спецов, чтобы стать, такими как Вы, ассами. Не у всех получится, однако пусть пытаются, пусть пробуют. Сами, что-ли никогда не ошибались. Команда еще молодая. Успехов ей
nezdhanov
22.11.2016 13:33+1Любая история чему-то учит, чему учит эта можно вообще обсуждать в отдельной статье… Мне больше интересно следующее: а товарищ этот американский(Кирилл), он там всю дорогу в одиночку работал или все-таки дружина у него все-таки была?
ildarz
Вот видите, хотели рассказать об одном, а рассказали о другом — как ваши ребята позабыли (?) про то, что планирование обычно делают до инсталляции, а не после, после чего в лучших традициях героически преодолели… :)
Gummio_7
С одной стороны вы совершенно правы, ildarz. Но дело в том, что серверы ставили в США, а пользователи в России. А во-вторых профили нагрузки заранее были не известны. Нет, конечно, лучше было бы все сделать сразу и хорошо… но у вас часто так бывает? :)
ildarz
Скажем так — допускаю, что проблема 2 действительно могла проявиться только в процессе эксплуатации, но 1 и 3 — совершенно чётко детские ошибки планирования. Оправдать это можно только в одном случае — если делали в первый раз (нет опыта) и в большой спешке (не было времени, чтобы хотя бы поверхностно ознакомиться с предметной областью). Если у ваших ребят нет привычки много раз наступать на одни и те же грабли, то ничего страшного, но я бы на месте их руководителя убедился, что урок усвоен правильно. :)
Gummio_7
Мы компания молодая (с января в таком виде работаем), так что да — неслаженность процессов имела место быть. Сами посмотрели, на ус намотали, если кому-то поможет избежать подобных ситуаций, будет очень хорошо!