Pull to refresh

Comments 23

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


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


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

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

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

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

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