service_ip, который на поды по rr что-то слать начнет - почти гарант того, что сеть(физически) кончится на машине, куда приземляется этот ip

ну а дальше про все эти “небольшие оверхеды” по той же сети… тут чуток, там маленько и на выходе у нас уже не очень приятные цифры, которые мы можем получить накрутив все эти слои.

ну а дальше про все эти “небольшие оверхеды” по той же сети… тут чуток, там маленько и на выходе у нас уже не очень приятные цифры, которые мы можем получить накрутив все эти слои.

ага т.е упираемся в сетку, и правильность распределения её нагрузки ?

ну и как, как они делают продукты в 2016 без IPv6 :(

ну и как, как они делают продукты в 2016 без IPv6 :(

этот аспект мы не будем трогать :)

любовно!

ага т.е упираемся в сетку, и правильность распределения её нагрузки ?

это больше похоже на “ёжики кололись, но продолжали есть кактусы”. Т.е. вроде вот он инструмент, все используют… может оно и мне надо? и начинаешь читать/проверять/ставить… а потом задаешь вопрос - а зачем вообще :)

потом еще возникает интересный момент: stateful контейнеры

т.е. нужен сторадж… т.е. это у нас nfs, iscsi, glusterfs, ceph

и начинаются новые горизонты

это больше похоже на “ёжики кололись, но продолжали есть кактусы”. Т.е. вроде вот он инструмент, все используют… может оно и мне надо? и начинаешь читать/проверять/ставить… а потом задаешь вопрос - а зачем вообще :)

так вопрос зачем, он на самом деле первый который возникает, и иногда докер и к8с решает проблемы, но обычно нет

хотел бы я, чтобы кибернетис их решал мне. но пока что-то нет.

стейтфул да известная проблема, но и для них есть старые добрые виртуалки

не, погоди - что решает в данном контексте виртуалка?

не, погоди - что решает в данном контексте виртуалка?

да ничего особо, я про то что стейтфул ненадо тащить в контейнеры, и пусть оно работает рядом по старому

я говорю о том, что pod может уметь переезжать на другую ноду - это отлично. Но для того, чтобы это работало я написал про сторадж.

изучение/внедрение которого тянет за собой массу всего.

Антон, а как вы решаете эту проблему со стородом ? хранилка + flocker ?

*хранилкой

да вот особо никак не решаем

просто ничего не помнят :)

как минимум нет решения, про которое я бы мог сказать, что за него не сильно стыдно, его просто настроить и оно применимо.

и больше всего меня огорчает факт того, что я пока не вижу чего-то вменяемого для этой хотелки, блин.

да ничего особо, я про то что стейтфул ненадо тащить в контейнеры, и пусть оно работает рядом по старому

тогда можно вешаться вообще

и больше всего меня огорчает факт того, что я пока не вижу чего-то вменяемого для этой хотелки, блин.

Не смотрели Virtuozo или Hedwig?

неа, про первое слышал от кого-то давно, про второе - не слышал

да и как-то не хочется сразу чего-то энтерпрайзного, большого и где все по заявлениям отлично

хочется на базе чего-то общепонятного и известного, чтобы как минимум максимально понимать происходящее

ибо практика говорит о том, что как только что-то готовое работать перестает ожидаемо - копать это и разбирать не всегда тривиально

мы сейчас смотрим на эти два. Еще специалистка про Docker Storage из некоей консалтинговой конторы Gartner мне рекомендовала посмотреть на Portworx, StorageOS или Blockbridge, но последние два скорее из-за наших специфичных требований на шифрование.

да и как-то не хочется сразу чего-то энтерпрайзного, большого и где все по заявлениям отлично

потом все равно придется переходить на энтерпрайзное и большое, так что лучше сразу k8s

потом все равно придется переходить на энтерпрайзное и большое, так что лучше сразу k8s

Как вариант посмотреть Rancher - он очень простой, и кубернетис может тебе поднять в один клик.

В нем через полгодика будет какой-то встроенный сторидж тоже, кстати

про ранчер знаю, да… но чот пока не зашел.

потом все равно придется переходить на энтерпрайзное и большое, так что лучше сразу k8s

почему придется?

о, спасибо

надо будет запомнить ранчер и попробовать в деле

почему придется?

потому что количество сервисов и частота деплоев растет, кастомные решения приходится писать самому, а в других местах это уже решено

В нем через полгодика будет какой-то встроенный сторидж тоже, кстати

ну k8s интегрируется в EBS и гугловским стораджем

ну вот как-то пока на данный момент решено там меньше, чем хотелось бы, если смотреть на текущие реалии.

ну и опять-таки кибернетис – это не что-то энтырпрайзное и т.д.

а что энтерпрайзное по-твоему?

у нас вот есть свой тулчейн на основе docker-compose и cloud formation, он хорош, но хочется перейти к более централизованному подходу

по гуглению “Не смотрели Virtuozo или Hedwig?” - похоже на “что-то энтерпрайзное“

vsphere - отличный вариант

как пример энтерпрайза.

ну k8s интегрируется в EBS и гугловским стораджем

Это хороший вариант. Вообще говоря любая система, поддерживающая докер сторадж-драйверы поддерживает все клаудные стораджа. Фишка Ранчер-стораджа (которого зовут Лонгхорн) в том, что он сам создает клаудный сторадж из вашего железа. Они это и называют “On-premise EBS”

Насколько я понимаю, сейчас есть 5 “энтерпрайз” решений для Докера: AWS ECC, Mesos, GCC k8s, Rancher, Docker DC

Есть еще всякие опенстеки, которые так же умеют как-то запускать контейнеры, но там все совсем несерьезно, и их стоит брать только за другую функциональность

“Фишка Ранчер-стораджа (которого зовут Лонгхорн) в том, что он сам создает клаудный сторадж из вашего железа.” но все мы понимаем, что чудес не бывает… и что на меди 1г, нормального стораджа врядли заиметь получится

@banuchka смотря для каких нужд он вам нужен. но вообще я требования 1г не учитывал, конечно. А на 10+ вполне может работать.

10г - это минимально требование, в том то и дело. Проблема в том, что на существующем парке это выливается тоже в затраты, чтобы получить 10г хотяб на кусок, где мне это нужно

нужда простая: пусть три апп-ноды, распределенное хранилище + переезд аппы в случае падения, с теми данными, что были на пред. ноде где оно работало.

без учета даунтайма на up/down аппы

RPO?

что? ну можно еще учесть, что аппа в процессе работы делает снепшоты в синхронном треде, т.е. совсем плохим io там сделать нельзя, а иначе задача бы сильно упростилась

допустим, что устроит 80% от RAID1+0 из 4х 10k SAS

RPO - recovery point objective. Сколько данных готовы потерять в случае отказа оборудования

тогда можно вешаться вообще

незнаю у меня счас на проекте сервис состоит из пикселя, веб уи, и 4х рест бекэндов, все это можно пихать в докер если надо проскейлиться, за этим конечно стоит база, но зачем мне базу в докер когда есть RDS

да, но не все задачи решает rds

иногда надо процессить сырые данные, которые приходят в виде файлов, например

emr же на спот инстансах

прочитал с с3 положил в базу или опять в с3

не очень охота спорить, но у этого тоже есть ограничения

хотя у нас есть продукт для этого, отлично работает, складывает в redshift

ERROR: S client not available

но редшифт стоит очень дорого

ну да варианты могут быть разными

на нашем трафике emr будет тормозить, поэтому у нас костыли

а какого типа трафик ?

вообще есть kinesis, но он тоже дорогой

2.5 терабайта логов в месяц

хм у нас было 20Г логов в день

это не логи доступа, а рабочие данные

у нас есть несколько кейсов, когда их нужно отфильтровать в реальном времени и отправить в другой сервис, который разошлет нотификации клиентам в течение 15 минут

а 15 минут уже интересней, у нас просто отчеты строились

обычно максимальная задержка минут 5

интересно, какая средняя

средняя задержка 3, лол

RPO - recovery point objective. Сколько данных готовы потерять в случае отказа оборудования

ну вообще привыкли не терять данные.

средняя задержка 3, лол

почти реалтайм

2 минуты задержки это два рсинка

один с серверов, которые собирают данные, второй с хранилища на обрабатывающий сервер

если б рсинк запускался чаще раза в минуту, то может было бы и получше

а крон не умеет секунды, ахаха

10/10, отлично

хм тебе бы потоковый рсинк

или что-то похожее

да ну что уж там, это не принципиально, и так хорошо

а крон не умеет секунды, ахаха

Пускай скрипт с флоком а внутри каждые 10сек рсинк и вейт

ну можно, но это как-то смешно и стыдно одновременно

надо будет предложить

И по-моему анакрон или какой то другой умеет в секунды

соседний отдел вот это продает:

http://www.ironsrc.com/atom/data-flow-management/

мы тоже пользуемся, но параллельно с нашим процессом

потому что исходные логи тоже надо хранить на всякий случай