Из вашего списка задач MCS решает только две:
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Это сильно натянутое заключение.
Мы получаем on-demand сервис с API, который нам позволяет получить произвольное число нод/CPU в считанные минуты независимо от времени суток. Скейлиться точно так же. Это справедливо для любого Kubernetes-aaS на самом деле, не только для MCS.
И фактически уйдя с bare-metal мы решили проблемы:
Все связанные с физическим оборудованием и своей OS:
— провиженинг
— деплоймент
— мониторинг
— апдейты
— замена комплектующих
т.е. все, что до kubectl apply.
В MCS файлы наши уже теряли…
Как там в анекдоте было, «админы делятся на два типа...»
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
У нас уже есть позитивный опыт решения подобных проблем с MCS.
Подробно рассказать не могу, но суть сводится к тому, что наш менеджер в MCS готов такие вопросы обсуждать и договариваться.
Там вообще три типа именно дисков: HDD, SSD, High IOPS SSD
«георепликация» — bool флаг для диска(High IOPS SSD его не умеют)
Обычно мы делаем кластер в одном регионе, диски к нему с георепликацией, там где это не контролируется (PVC) и/или невозможно(High IOPS SSD) — не настаиваем, т.к. репликация есть внутри statefulset'а.
За все время использования Kubernetes на bare-metal мы пробовали разные варианты(в хронологическом порядке):
— Внешний сторадж с дисковой полкой и LVM over FC
— Оно же over iSCSI
— Локальный Ceph на нодах
— hostPath + nodeSelector
В GCP и MCS мы используем предоставляемые вендором сервиса внешние вольюмы через PVC. Не локальное хранилище на нодах(hostPath) потому что это сильно повлияет на отказоустойчивость и потребует ручного управления StatefulSet'ами, что хочется оставить соответствующим операторам.
Ещё в статье написано, что вы данные храните в Kubernetes, можно поконкретнее, где именно?
Да, конечно, для хранения данных экологического мониторинга мы используем Kafka и ScyllaDB, запущенные в виде StatefulSet'ов с PVC, преимущественно на SSD.
Попутно пробуем операторы для stateful-приложений, но для Kafka и ScyllaDB пока не нашли подходящего решения.
Как вы решили задачу с контролем физического местонахождения данных?
Помимо собственно самих данных у нас есть компоненты отвечающие за аутентификацию, авторизацию, рассылку уведомлений, самый простой пример: для каждого пользователя мы можем хранить email, Ф.И.О., номер телефона, организацию пользователя — сочетание этих данных дает уже ПД.
Не, не понимаю.
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Распределение ресурсов команд это вопрос продукт-, проджект- и релиз-менеджмента.
В самом начале у нас было именно так — 8 серверов и с ними вполне справлялись разработчики, но затем, как у любого развивающегося проекта у нас появились задачи:
— воспроизводимости окружения
— апгрейдов kubernetes
— интеграции kubernetes с корпоративными сервисами
— трейсинга ошибок наших собственных приложений
— мониторинга
— централизованного доступа к логам
— CI
— CD
— процедур и сервисов для Code Review
— песочницы для экспериментов
— SLA и отслеживание его соблюдения
… этот перечень можно еще продолжать, но важно одно: это все не задачи разработчиков продуктовой команды. Это инфраструктурные задачи.
Все это нужно для того, чтоб команда разработки могла эффективно выполнять свои функции, а именно:
— занималась разработкой
— делала это с максимальной эффективностью
— т.е. не отвлекаясь на задачи инфраструктуры
— имея при этом воспроизводимый результат
— и наиболее свежие технологии в стеке
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Продуктовые задачи это не только обсчет данных, это целый набор задач по архитектуре сервисов, UI/UX, непосредственно арифметике и, самое главное, применимости конкретных экологических методик к нашим реалиям и целям.
Не понимаю чем два человека на Full-time занимались.
Ровно всем этим — обеспечивали работу остальных команд, беря на себя инфраструктурные функции и организацию процессов.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Это самая интересная часть — еще переезжая в GCP(где, кстати есть возможность Interconnect'а с корпоративными сегментами) мы осознали что, это лишнее. У нас ушло понимание зачем нам держать сервис(даже его девелопмент часть) исключительно во внутренней сети. Так что в MCS мы приехали с полностью публично-доступными(в сетевом смысле этого слова) сервисами, а дальше — BeyondCorp model(хотя к полной ее имплементации мы еще только стремимся).
Читаю и у меня, что-то не сходится, вопросы возникают.
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Получилось дешевле за счет того, что это managed-решение, которое не требует с нашей стороны разработки low-level компонентов, например для интеграции с сетью компании или для PVC на своем оборудовании.
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
«Сколько» это в человеко-часах, два человека — DevOps на full-time + переодически привлекаемые разработчики под частные задачи, когда они накапливались.
Разрабатывали, например, компонент позволяющий в сервисах использовать IP'шники из корпоративной сети, интегрирующийся так же с DNS. В опенсорс он в итоге не пошел. Так же делали stage3 провижнинг нод с автодобавлением в кластер и апгрейдом кубернетеса, хотели перейти на stage4 с тестами конкретной сборки, но не успели :)
В настоящий момент у нас сырых пожатых данных всего ничего ~5GB в Kafka(~5M сообщений от конечных устройств), переливали мы их без нарушения работоспособности сервиса. Так что полчаса для такого объема даже очень долго :)
Суммарно используется 85 CPU, 322 GB RAM.
Общий объем CPU и памяти у нас обычно зависит от того, над чем мы эксперементируем в настоящий момент и какие стоят задачи, текущее значение достаточно скромное, потому что сейчас не проходит никаких экспериментов.
Если речь об OpenPaths(https://openpaths.cc) то существенных отличий от латитьюда я не вижу, как по безопасности, так и по сохранности своих данных, хранящихся там.
У моего проекта в корне другая идеология, он изначально создавался с другой целью, но архитектура и используемые технологии позволяют использовать и как латитьюд. Кроме того, проект под GPLv2, исходный код открыт, Вы можете установить его себе и использовать именно свою копию, тогда сохранность данных вы будете контролировать сами :)
В выходные могу еще кстати сделать http-ручку, для добавления сообщений через HTTP-POST запрос, чтобы не изгаляться с транслированием в странные форматы, заодно на нее же можно перевести trackkrd, что избавит его от использования ORM'а.
Ридми поправил, описал там как запускать и как запускать приложенный там же эмулятор трекера :)
О модульности можно подумать, пока trackkrd сделан так, чтобы быть максимально быстрым и простым, нагрузочного тестирования на него пока не проводилось, как узнаю сколько он держит rps(скорее даже не он, а питонячий TCPServer), станет ясно имеет ли смысл нагружать его. Пока же можно просто модифицировать регэксы.
Пожалуйста, если найдете какие странности/проблемы, не стесняйтесь создавать таску на гитхабе ;)
Угу… я тогда как раз был в отпуске, как приходит мне смска, мол вам подключили эту услугу… пришлось звонить и спрашивать на кой черт они мне ее подключили, когда я не просил… Видимо, в скором времени меня даже сохранение номера не удержит от того, чтобы с ними расстаться…
Это сильно натянутое заключение.
Мы получаем on-demand сервис с API, который нам позволяет получить произвольное число нод/CPU в считанные минуты независимо от времени суток. Скейлиться точно так же. Это справедливо для любого Kubernetes-aaS на самом деле, не только для MCS.
И фактически уйдя с bare-metal мы решили проблемы:
Все связанные с физическим оборудованием и своей OS:
— провиженинг
— деплоймент
— мониторинг
— апдейты
— замена комплектующих
т.е. все, что до
kubectl apply
.Как там в анекдоте было, «админы делятся на два типа...»
У нас уже есть позитивный опыт решения подобных проблем с MCS.
Подробно рассказать не могу, но суть сводится к тому, что наш менеджер в MCS готов такие вопросы обсуждать и договариваться.
«георепликация» — bool флаг для диска(High IOPS SSD его не умеют)
Обычно мы делаем кластер в одном регионе, диски к нему с георепликацией, там где это не контролируется (PVC) и/или невозможно(High IOPS SSD) — не настаиваем, т.к. репликация есть внутри statefulset'а.
— Внешний сторадж с дисковой полкой и LVM over FC
— Оно же over iSCSI
— Локальный Ceph на нодах
— hostPath + nodeSelector
В GCP и MCS мы используем предоставляемые вендором сервиса внешние вольюмы через PVC. Не локальное хранилище на нодах(hostPath) потому что это сильно повлияет на отказоустойчивость и потребует ручного управления StatefulSet'ами, что хочется оставить соответствующим операторам.
Да, конечно, для хранения данных экологического мониторинга мы используем Kafka и ScyllaDB, запущенные в виде StatefulSet'ов с PVC, преимущественно на SSD.
Попутно пробуем операторы для stateful-приложений, но для Kafka и ScyllaDB пока не нашли подходящего решения.
Не понял вопроса.
Распределение ресурсов команд это вопрос продукт-, проджект- и релиз-менеджмента.
В самом начале у нас было именно так — 8 серверов и с ними вполне справлялись разработчики, но затем, как у любого развивающегося проекта у нас появились задачи:
— воспроизводимости окружения
— апгрейдов kubernetes
— интеграции kubernetes с корпоративными сервисами
— трейсинга ошибок наших собственных приложений
— мониторинга
— централизованного доступа к логам
— CI
— CD
— процедур и сервисов для Code Review
— песочницы для экспериментов
— SLA и отслеживание его соблюдения
… этот перечень можно еще продолжать, но важно одно: это все не задачи разработчиков продуктовой команды. Это инфраструктурные задачи.
Все это нужно для того, чтоб команда разработки могла эффективно выполнять свои функции, а именно:
— занималась разработкой
— делала это с максимальной эффективностью
— т.е. не отвлекаясь на задачи инфраструктуры
— имея при этом воспроизводимый результат
— и наиболее свежие технологии в стеке
Продуктовые задачи это не только обсчет данных, это целый набор задач по архитектуре сервисов, UI/UX, непосредственно арифметике и, самое главное, применимости конкретных экологических методик к нашим реалиям и целям.
Ровно всем этим — обеспечивали работу остальных команд, беря на себя инфраструктурные функции и организацию процессов.
Это самая интересная часть — еще переезжая в GCP(где, кстати есть возможность Interconnect'а с корпоративными сегментами) мы осознали что, это лишнее. У нас ушло понимание зачем нам держать сервис(даже его девелопмент часть) исключительно во внутренней сети. Так что в MCS мы приехали с полностью публично-доступными(в сетевом смысле этого слова) сервисами, а дальше — BeyondCorp model(хотя к полной ее имплементации мы еще только стремимся).
Получилось дешевле за счет того, что это managed-решение, которое не требует с нашей стороны разработки low-level компонентов, например для интеграции с сетью компании или для PVC на своем оборудовании.
«Сколько» это в человеко-часах, два человека — DevOps на full-time + переодически привлекаемые разработчики под частные задачи, когда они накапливались.
Разрабатывали, например, компонент позволяющий в сервисах использовать IP'шники из корпоративной сети, интегрирующийся так же с DNS. В опенсорс он в итоге не пошел. Так же делали stage3 провижнинг нод с автодобавлением в кластер и апгрейдом кубернетеса, хотели перейти на stage4 с тестами конкретной сборки, но не успели :)
В настоящий момент у нас сырых пожатых данных всего ничего ~5GB в Kafka(~5M сообщений от конечных устройств), переливали мы их без нарушения работоспособности сервиса. Так что полчаса для такого объема даже очень долго :)
Суммарно используется 85 CPU, 322 GB RAM.
Общий объем CPU и памяти у нас обычно зависит от того, над чем мы эксперементируем в настоящий момент и какие стоят задачи, текущее значение достаточно скромное, потому что сейчас не проходит никаких экспериментов.
А с переездом в облако все уже сделали за нас :)
Вопрос: почему именно Encfs? Судя по скриншотам вы используете Mac OS X, там есть нативное средство создания контейнеров — File Vault 2.
У моего проекта в корне другая идеология, он изначально создавался с другой целью, но архитектура и используемые технологии позволяют использовать и как латитьюд. Кроме того, проект под GPLv2, исходный код открыт, Вы можете установить его себе и использовать именно свою копию, тогда сохранность данных вы будете контролировать сами :)
О модульности можно подумать, пока trackkrd сделан так, чтобы быть максимально быстрым и простым, нагрузочного тестирования на него пока не проводилось, как узнаю сколько он держит rps(скорее даже не он, а питонячий TCPServer), станет ясно имеет ли смысл нагружать его. Пока же можно просто модифицировать регэксы.
Пожалуйста, если найдете какие странности/проблемы, не стесняйтесь создавать таску на гитхабе ;)
Когда гуглил что эта штука может отправлять выяснилось что протокол у них всех весьма схожий :)
Ставится только через Empire EFI, но рухает после апдейта:(