Pull to refresh

Comments 24

Даю простую задачу: решить проблему зависания SAS шины при зависании диска, решить проблему с замедлением работы софтового свичта при увеличении числа flow, обеспечивать хотя бы 500-700 мегабит до виртуалок любого размера пакетами.

Хехе, городить стек все горазды, а вы базис сделайте-то…
День добрый,
Перелопатил все обращения клиентов, к счастью таких проблем никто не озвучивал.
Вероятнее всего, либо нет нормальной нагрузки, либо не могут сформулировать претензию за «внезапно затормозило»/«упало».
Как обычно решают проблему зависания SAS шины? Если диск вышел из строя и стал флудить в SAS шине, диск надо извлечь, произойдет терминирование, и проблема исчезнет. Как мы решаем эту проблему — архитектурно, устраняя проблему как единую точку отказа. А как решили в своем облаке эту проблему вы?
Проблема зависания софтверного свитча нами исследуется и сейчас мы ее не испытываем. Так же как и с зависанием SAS шины, возможен архитектурный обход этой проблемы.
Считаю утверждение про стек субъективным. Используя KVM виртуализацию, OpenVSwitch и прочие opensource пакеты мы не изобрели велосипед, а Openstack – оркестратор процессов, который достаточно легко «дописывается».
Предлагаю продолжить общение в кулуарах, если это имеет смысл.
Дайте добро на небольшую dos атаку (15-20 мегабит) на IP'шник, запущенный на OVS'е. будет смешно.
Наши тесты пока не выявили таких проблем. Если Вы можете подсказать структуру DoS-атаки для дополнительной проверки, можем продолжить обсуждение по почте или в личке.
IP, 20 мегабит входящего трафика == недоступный на время атаки хост, где находится атакующая виртуалка.

Если бы вы серьёзно относились к используемому ПО, то вы бы читали рассылки разработчкиков. Я писал там про проблему и даже засылал патч для её решения.
И что разработчики? Уже пофиксили?
Нет, потому что мой патч делает OVS устройчивым в всякой мерзкости, но нехорошо забивает на высокие идеалы SDN. В результате они решили, что лучше строить замки на песке, чем заниматься котлованами под фундамент.

Тут проявляется позиция, характерная для опенстека. Не будем лечить и латать узкие места, прсото скажем — используется горизонтальное масштабирование. Поставьте еще 10 серверов =)).
Используя KVM виртуализацию, OpenVSwitch и прочие opensource пакеты мы не изобрели велосипед, а Openstack – оркестратор процессов, который достаточно легко «дописывается»

А вот тут можно чуточку поподробнее? Что вы использовали из OpenStack, а что «дописывали» сами?
Используем релиз Grizzly и все основные компоненты OpenStack, за исключением Swift. Из изменений – в принципе адаптировали под себя каждый проект, в некоторых проектах доработали логику и функционал, например, Floating IP и маршрутизации в сетевой части (Quantum), адаптировали пребиллинг (Ceilometer) под свои задачи.
Так инфраструктура сама разворачивается или заказчик «рисует» что он хочет, а потом специальные люди это разворачивают?
Структура строится и автоматически разворачивается по мере того, как вы «рисуете».
Прочитал и получил неожиданное впечатление статьи «ни о чем»
Картинки и текст производят впечатление чего-то умного, мощного и хорошего. А если подумать — есть openstack и openvswitch. Вы их взяли. А дальше что? Где ноухау? Где что-то новое?

Да тысячам юзеров не нужен vlan и они понятия не имеют зачем он им. И да у openvswitch есть проблемы с производительностью на большом числе мелких пакетов. Было бы интереснее, если бы Вы брали железный свич умеющий openflow и про него написали.
А что собственно вы имеете ввиду под ноухау?
Кто мешает любому взять опенстек и тоже самое ПО и сделать тоже самое или даже лучшее? Чем Вы лучше? Что особенного Вы предлагаете?
Ноухау — openshift, juju (https://juju.ubuntu.com/), heroku местами…
Вы абсолютно правы. Никто никому не мешает взять и сделать лучше. :) Если серьезно, то не хочется «покусочничать». Мы готовим ряд статей, из которых, надеюсь, вы составите себе цельную картину о том, что мы сделали.
Хорошо. Почитаем. А еще вопрос — как делали имаджи для операционок?
В ближайшее время мы продолжим серию статей, в которых расскажем про нашу архитектуру и о том, какие изменения мы в несли в OpenStack. В первой статье 23.01.2013 мы рассказали о проектировании сетевой части habrahabr.ru/company/iteco/blog/166729/
А сейчас как-то можно это всё протестировать? Обычно предлагают триальный период или что-то такое.
Да, забыл. К каждому тестовому серверу прилагается «белый» IP
Конечно. Мы предоставляем двухнедельный тестовый период на ряд конфигураций.
Sign up to leave a comment.