Да, конечно, вы правы. Многое можно было сделать лучше — и сейчас это понятно. Но у нас был такой первый опыт, и захотелось им поделиться. Может кому-то удастся учиться на наших ошибках, мы же поучились на своих. Все вышло благополучно, результат достигнут… ну а доказывать, что мы супер все подготовили и спланировали цели не было. Можно было запланировать, сделать заявку в штаты, разработать план, привлечь кучу людей, потратить на это кучу денег и ресурсов… но вышел такой опыт — может кому-то кажется полезен.
Не по максимуму, а «там где надо», и что спланировано было недостаточно — выяснилось в процессе эксплуатации, когда подсистема хранения стала давать очень большие нагрузки на сеть. Но в целом, да, вы правы. Пример успешного решения классической задачи повышения эффективности, но с трансокеанскими переменными. И текст, не о том, что перепланировали, а о том, что успешно решили задачу за несколько часов, по удаленке и сами себе доказали, что выделение стораджа в отдельный сегмент сети на отдельных сетевых карточках дал серьезный рост производительности в целом. Для нас была ценная находка, если вам и так очевидно, то слава богу!
Мы компания молодая (с января в таком виде работаем), так что да — неслаженность процессов имела место быть. Сами посмотрели, на ус намотали, если кому-то поможет избежать подобных ситуаций, будет очень хорошо!
Не, с Киром все нормально. Может конечно и «пришли», но он из ЦОДа уже успешно ушел и даже после этого выходил на связь… правда в Telegram по шифрованному каналу. :)
dvsx86, вы слишком часто читаете девчачьи дневнички, раз такие ассоциации. )))
Мы уплотнили количество ВМок вдвое. Пришли к выводу, что при группировке стораджа на отдельные интерфейсы, производительность при тестовых прогонах выросла в разы (при интенсивных нагрузках тестирования ПО). Если вам эта информация не интересна, проходите дальше, не претендуем на авторитетное тестирование и сравнение — это случай из жизни нормальных тестировщиков, вынужденных работать на железе, к которому нет физического доступа.
И да, хабр — не торт. Никто не сомневался. :)
С одной стороны вы совершенно правы, ildarz. Но дело в том, что серверы ставили в США, а пользователи в России. А во-вторых профили нагрузки заранее были не известны. Нет, конечно, лучше было бы все сделать сразу и хорошо… но у вас часто так бывает? :)
Нет, имеется в виду KVM+Qemu (да, не совсем точно выразились) — то есть именно KVM, а не какой-то другой гипервизор (например XEN).
Далее, слабое место — это общее ядро — если из одного контейнера удаётся «сломать» его, то ломаются все контейнеры. Кроме того, ядро большое, сделать его безопасным ВСЁ невозможно, получается, что либо мы предоставляем контейнеру пользоваться лишь небольшим набором функций (а остальные запрещаем), либо даём ему всё, но учитываем риск получить «дырку» в безопасности.
Все верно, но при этом запуск внутри ВМ используется сегодня, как дополнительный уровень изоляции. Применять его или нет — дело выбора и конкретной ситуации.
Мы уплотнили количество ВМок вдвое. Пришли к выводу, что при группировке стораджа на отдельные интерфейсы, производительность при тестовых прогонах выросла в разы (при интенсивных нагрузках тестирования ПО). Если вам эта информация не интересна, проходите дальше, не претендуем на авторитетное тестирование и сравнение — это случай из жизни нормальных тестировщиков, вынужденных работать на железе, к которому нет физического доступа.
И да, хабр — не торт. Никто не сомневался. :)
Далее, слабое место — это общее ядро — если из одного контейнера удаётся «сломать» его, то ломаются все контейнеры. Кроме того, ядро большое, сделать его безопасным ВСЁ невозможно, получается, что либо мы предоставляем контейнеру пользоваться лишь небольшим набором функций (а остальные запрещаем), либо даём ему всё, но учитываем риск получить «дырку» в безопасности.