Ну, вопрос изначально стоял на уровне опенсорсить его или нет.
И тем не менее, компаний предоставляющих аналогичный по ТТХ сторадж в мире нет
Собственно, если этот вариант отпадает (уникальности особо ни в чем нет), значит, опенсорсить в первую очередь имеет смысл такую распространенную и востребованную вещь как распределенный сторадж, а во вторую — такую узкоспециализированную, как контроллер программной сети :). Я точно не буду выкладывать сравнения, потому что формально заинтересован в том, чтобы выставить цеф в положительном свете и ссылаться на итоги для привлечения клиентов. Вариант сам намерял — сам горжусь мы не используем.
Fuse там действительно быстрый, само решение в целом дает меньшие, чем Ceph, цифры, бенчмарки я проводил для себя. Вот бенчмарков от производителя, подтверждающих обратное, я не вижу, даже ребята из гластера еще до покупки редхатом цефа нашли конфигурацию, на которой гластер работал лучше. Сравнивать то, как работает fuse, с механизмом зерокопи в упомянутых фреймворках, ну очень странно :)
И тем не менее, компаний предоставляющих аналогичный по ТТХ сторадж в мире нет :) Так что тут явный риск, да и интеллектуальная собственность.
WHAT. Если просто поставить цеф и эту систему на одно и то же железо, там будет разница в разы по суммарным бенчмаркам стораджа, и не в пользу решения от Parallels. Собственно, зачем мне завязываться на сущность, работающую через FUSE и делающую это хуже, чем опенсоурсный аналог?
Но Ваш код — Ваше решение. Я за здравый подход к опенсорцу, просто в Вашем случае он странный
Я же написал, что ни один стандарт из нумерованных не поддерживается на сто процентов. Нам придется тратить усилия а) на полную поддержку стандарта, б) на обновления стандарта (вышел OF 1.5 — вперед, и так далее), в) на изобретение и поддержку дополнительной прослойки, которая бы отвязывала контроллер от оркестровки и делала бы его юзабельным для других оркестровок, в ответ же получим ранний адопшен (зачем?) и конкуренцию (зачем?). Такое себе можно позволить, если *не* являться производителем и потребителем услуги одновременно, совмещенных вариантов в мире я что-то не встречаю, да и мы не профильный вендор, чтобы вбухивать собственные деньги на поддержку публичного решения, имеющего десяток закрытых и десяток открытых аналогов.
Хорошо, тем не менее, сторедж закрыт и открываться или делиться хотя бы архитектурными идеями не спешит (кроме того, что в целом это +- отвечает Ceph/Nutanix на самом абстрактном уровне). Биллинг даже уберу из примера, это исключительно коммерческая сущность и она имеет право быть закрытой. Бесплатный для малых объемов — идеальный вариант подсадки на любой наркотик =).
Вы немножко лукавите — ключевая функциональность напрочь закрыта и открывать ее никто не будет. Безусловно, вся закрытая часть относится к юзерспейсу, поскольку поддерживать закрытый ядерный код — тяжелая и бессмысленная задача. То соотношение открытых и закрытых частей, которое достигнуто у всех вендоров, определяется не их идеологией, а только и исключительно оптимизацией расходов.
Это взаимодействие между заказчиком и потребителем, комьюнити получает результаты постольку, поскольку не закрывать же их от публики. К требованию открытости кода не имеет ровным счетом никакого отношения (кроме того, что если бы openvz разрабатывался закрыто, нужные куски никогда бы не попали в мастер). У нас иная модель — там, где мы используем готовые стеки, активно взаимодействуем с разработчиками на предмет устранения ошибок, а собственные стеки самодостаточны и открытие их не принесет ровным счетом ничего, кроме дополнительной конкуренции собственным же продуктом :).
Там, где мы ими воспользовались, ответы оплачены багрепортами в очень неплохих количествах, ну и доделки к опенсорсной части мы не закрываем. Смысл выбрасывать что-то в опенсорс есть только тогда, когда речь идет о компоненте, которая встраивается во множество инфраструктур (это суровая правда, в отличие от пропаганды опенсорса). Выкладывать полноценное инфраструктурное решение в общий доступ бессмысленно, его просто заберет крупняк и все, какого-либо значимого фидбека не возникнет. Достаточно посмотреть на текущее состояние опенстека, который уже раздробился ровно таким образом, несмотря на то. что работает, в общем, намного хуже, чем закрытые платформы. В качестве эксперимента могу предложить написать в Parallels письмо с просьбой об открытии PCS или RH об опубликовании флагов сборки пакетов — поскольку эти вещи являются существенно более нишевыми и имеют намного больше точек сопряжения с остальным софтом, начать стоит с них :).
Защита есть, конечно. Преимуществ от открытия кода под GPL ровно 0, потому что наши хотелки идут перпендикулярно потенциальным потребностям комьюнити, под BSD так вообще польза отрицательна — крупные игроки возьмут готовое решение и закроются, а потребности во внешнем багрепортинге у нас нет. К тому же, нам нет нужды поддерживать у себя стандарт на сто процентов, так что решение точно не для публики. Если мы и заопенсорсимся, то скопом.
Нет смысла его открывать — он не поддерживает на сто процентов стандарт и в плане логики сцеплен с оркестровкой. Почему, нетмап умеет прекрасно весь джентльменский набор карточек, так что встроить его к себе — вопрос чисто практической потребности.
Контроллер свой, все открытое неработающее до отвратительности, да. PF_RING — это аналог нетмап+пкап, никакого плюса для собственно транфера не дает, то есть если говорить о контейнерах, пока мы используем venet/pair, характеристики сетевого трафика будут очень и очень скромными. VF, вообще говоря, это не технология, которую можно раздавать в публичном сегменте, так что здесь вендор хостинга лимитирован чисто софтовыми вариантами (и да, 64 vf, особенно если машина толстая а контейнеризованные приложения имеют небольшой отпечаток в памяти, может не хватить, придется ставить вторую карточку).
Не пойдет, мало vf и отрывается лайв миграция, плюс это не особо чтобы фильтруется мейнстримовыми средствами в пределах ноды. Ну и 14 Mpps он все же не дает, лайн рейт на 82599 достижим только на нетмапе пожалуй. habrahabr.ru/company/performix/blog/224211/ тут я упоминал про нетлинк для фильтрации, но это непринятая никуда экзотика.
veth pair/virtio — еще одна болезнь, мешающая работать высокопроизводительным решениям. Сто тысяч пакетов в секунду без mq(* 2...3 с mq-tx) makes me sad panda. У пары впрочем все на примерно сотне тысяч и заканчивается насовсем.
Я не думаю, что они хотя бы на волос отдалились от существующих проблем безопасности. То, что у них на главной написано — это позиционирование для продаж, а не технологическое преимущество. Речь выше шла как раз про энтерпрайзный сегмент (внутренние облака) и остальных (паблик), пользователи ovz присутствуют только во втором, а это только и исключительно мелкая розница.
Из операторов — никто. Контейнеры это прекрасное решение для устранения оверхеда, связанного с решедулингом, но в качестве платы — дырявы. Использовать их можно либо для хоум страничек (в недоверенном сегменте, т.е. публичный хостинг) или для всего остального во внутренней инфраструктуре. Использование хостинговыми операторами контейнеров для крупняка по этим причинам нулевое. Да, 3.12 не LTS, а шляпа еще к себе в 7 не затащила изменения вроде бы.
Ну ovz в энтерпрайзе во внутренних облаках использует почти ровным счетом никто, а docker — массово. Вопрос, в первую очередь, в позиционировании и в сопутствующем софте. Если я — пользователь и про оба решения слышал одинаково мало, я выберу то, что ставится без необходимости юзать ядро со стороны и то, что проще, у энтерпрайзов примерно такая же логика.
Собственно, если этот вариант отпадает (уникальности особо ни в чем нет), значит, опенсорсить в первую очередь имеет смысл такую распространенную и востребованную вещь как распределенный сторадж, а во вторую — такую узкоспециализированную, как контроллер программной сети :). Я точно не буду выкладывать сравнения, потому что формально заинтересован в том, чтобы выставить цеф в положительном свете и ссылаться на итоги для привлечения клиентов. Вариант сам намерял — сам горжусь мы не используем.
WHAT. Если просто поставить цеф и эту систему на одно и то же железо, там будет разница в разы по суммарным бенчмаркам стораджа, и не в пользу решения от Parallels. Собственно, зачем мне завязываться на сущность, работающую через FUSE и делающую это хуже, чем опенсоурсный аналог?
Я же написал, что ни один стандарт из нумерованных не поддерживается на сто процентов. Нам придется тратить усилия а) на полную поддержку стандарта, б) на обновления стандарта (вышел OF 1.5 — вперед, и так далее), в) на изобретение и поддержку дополнительной прослойки, которая бы отвязывала контроллер от оркестровки и делала бы его юзабельным для других оркестровок, в ответ же получим ранний адопшен (зачем?) и конкуренцию (зачем?). Такое себе можно позволить, если *не* являться производителем и потребителем услуги одновременно, совмещенных вариантов в мире я что-то не встречаю, да и мы не профильный вендор, чтобы вбухивать собственные деньги на поддержку публичного решения, имеющего десяток закрытых и десяток открытых аналогов.
Из операторов — никто. Контейнеры это прекрасное решение для устранения оверхеда, связанного с решедулингом, но в качестве платы — дырявы. Использовать их можно либо для хоум страничек (в недоверенном сегменте, т.е. публичный хостинг) или для всего остального во внутренней инфраструктуре. Использование хостинговыми операторами контейнеров для крупняка по этим причинам нулевое. Да, 3.12 не LTS, а шляпа еще к себе в 7 не затащила изменения вроде бы.