Pull to refresh
10
0
Игорь @t3ran

Пользователь

Send message
Из вашего списка задач 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 и памяти у нас обычно зависит от того, над чем мы эксперементируем в настоящий момент и какие стоят задачи, текущее значение достаточно скромное, потому что сейчас не проходит никаких экспериментов.

А с переездом в облако задача просто отпала?

А с переездом в облако все уже сделали за нас :)
Интересная статья, спасибо. У меня как раз такая проблема — сохранить несколько сотен гигабайт в облаке :)

Вопрос: почему именно Encfs? Судя по скриншотам вы используете Mac OS X, там есть нативное средство создания контейнеров — File Vault 2.
Если речь об OpenPaths(https://openpaths.cc) то существенных отличий от латитьюда я не вижу, как по безопасности, так и по сохранности своих данных, хранящихся там.

У моего проекта в корне другая идеология, он изначально создавался с другой целью, но архитектура и используемые технологии позволяют использовать и как латитьюд. Кроме того, проект под GPLv2, исходный код открыт, Вы можете установить его себе и использовать именно свою копию, тогда сохранность данных вы будете контролировать сами :)
С трекером ничего не шло, гуглил и реверс-инжинировал:)
текстовые сообщения через tcp-протокол, примеры можно посмотреть на гитхабе в tracker_emulator.py
В выходные могу еще кстати сделать http-ручку, для добавления сообщений через HTTP-POST запрос, чтобы не изгаляться с транслированием в странные форматы, заодно на нее же можно перевести trackkrd, что избавит его от использования ORM'а.
О, круто, если какие вопросы будут — пишите в джаббер :)
Ридми поправил, описал там как запускать и как запускать приложенный там же эмулятор трекера :)

О модульности можно подумать, пока trackkrd сделан так, чтобы быть максимально быстрым и простым, нагрузочного тестирования на него пока не проводилось, как узнаю сколько он держит rps(скорее даже не он, а питонячий TCPServer), станет ясно имеет ли смысл нагружать его. Пока же можно просто модифицировать регэксы.

Пожалуйста, если найдете какие странности/проблемы, не стесняйтесь создавать таску на гитхабе ;)
Вот такая: www.ebay.com/itm/Quad-band-Spy-Vehicle-Realtime-GPS-GSM-GPRS-S-MS-Tracker-Device-TK102B-with-buli-/181030960666?pt=US_Tracking_Devices&hash=item2a26493e1a

Когда гуглил что эта штука может отправлять выяснилось что протокол у них всех весьма схожий :)
Сама идея вполне нормальная и удобная, у самого правила iptables генерятся ruby-скриптом;)
Это не услуга, это фактор, который сдерживает меня от перехода к другому ОпСоСу :)
Угу… я тогда как раз был в отпуске, как приходит мне смска, мол вам подключили эту услугу… пришлось звонить и спрашивать на кой черт они мне ее подключили, когда я не просил… Видимо, в скором времени меня даже сохранение номера не удержит от того, чтобы с ними расстаться…
А на Core i7-860 у кого-нить завелось? Мне говорит Unsopported CPU family
Ставится только через Empire EFI, но рухает после апдейта:(

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity