Прежде всего пример выше на Java, а речь в статье про Go SDK (как и все примеры на Go). И там особенность какая, у метода PutObject есть параметр objectSize int64, и его так же можно поставить в -1, но явно говорят:
objectSize
int64
Size of the object being uploaded. Pass -1 if stream size is unknown (Warning: passing -1 will allocate a large amount of memory)
Потому так и написано, что нужно знать размер (иначе может быть больно) :)
Во многих решениях для оркестрации виртуальных машин есть возможность резервирования ресурсов под нужды гипервизора так умеет делать и Openstack. Расход памяти OSD-демонами при этом можно предсказать исходя из объема дисков, так можно уместиться в оперативку если правильно подобрать коэффициент и учесть потребности ОС гипервизора. SWAP при этом мы не используем совсем.
Для CPU немного интереснее, но смысл примерно в том же, nova умеет как резервировать CPU так и использовать конкретные ядра CPU в shared-режиме (через все тот же cpuset), посколько аллокацию CPU для OSD мы знаем из документации Ceph - остается просто забронировать нужное количество ресурса с учетом допустимых коэффициентов и на них не будет приходить нагрузка от виртуальных машин :)
Вообще нельзя сравнивать SMB/NFS и Ceph напрямую - это крайне разные вещи. Ceph - SDS, а SMB и NFS - протоколы доступа к данным.
Есть, кстати, официальная реализация NFS поверх Ceph (CephFS либо RadosGW (S3) в качестве бекенда на выбор), аналогичное по архитектуре можно провернуть и с SMB, в целом.
Ну а про производительность - это весьма сложная тема. Во-первых, потому что в какой-то мере производительность - цена безопасности (safety) и доступности, во-вторых потому что на нее влияет множество факторов, ну и в третьих раз мы говорим про сетевой доступ, то к сложности производительности IO добавляется сложность производительности сети.
Но если нам не нужно все и мы хотим условно "apt-get install nfs" и с этим запускаться, то в базовом варианте NFS в большинстве случаев (есть исключения) будет быстрее по IO чем CephFS, запущенная на этой же одной ноде с этим же количеством дисков.
Но одновременно с этим, NFS нельзя будет масштабировать ни по (общей) производительности ни по объему, поставив рядом еще один/два/три/пять серверов. Ну и само-собой отказоусточивость и доступность нужно как-то самостоятельно гарантировать.
Из вашего списка задач 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), станет ясно имеет ли смысл нагружать его. Пока же можно просто модифицировать регэксы.
Пожалуйста, если найдете какие странности/проблемы, не стесняйтесь создавать таску на гитхабе ;)
Прежде всего пример выше на Java, а речь в статье про Go SDK (как и все примеры на Go). И там особенность какая, у метода PutObject есть параметр objectSize int64, и его так же можно поставить в -1, но явно говорят:
Потому так и написано, что нужно знать размер (иначе может быть больно) :)
Вопрос действительно со звездочкой :)
Во многих решениях для оркестрации виртуальных машин есть возможность резервирования ресурсов под нужды гипервизора так умеет делать и Openstack. Расход памяти OSD-демонами при этом можно предсказать исходя из объема дисков, так можно уместиться в оперативку если правильно подобрать коэффициент и учесть потребности ОС гипервизора. SWAP при этом мы не используем совсем.
Для CPU немного интереснее, но смысл примерно в том же, nova умеет как резервировать CPU так и использовать конкретные ядра CPU в shared-режиме (через все тот же cpuset), посколько аллокацию CPU для OSD мы знаем из документации Ceph - остается просто забронировать нужное количество ресурса с учетом допустимых коэффициентов и на них не будет приходить нагрузка от виртуальных машин :)
Вообще нельзя сравнивать SMB/NFS и Ceph напрямую - это крайне разные вещи. Ceph - SDS, а SMB и NFS - протоколы доступа к данным.
Есть, кстати, официальная реализация NFS поверх Ceph (CephFS либо RadosGW (S3) в качестве бекенда на выбор), аналогичное по архитектуре можно провернуть и с SMB, в целом.
Ну а про производительность - это весьма сложная тема. Во-первых, потому что в какой-то мере производительность - цена безопасности (safety) и доступности, во-вторых потому что на нее влияет множество факторов, ну и в третьих раз мы говорим про сетевой доступ, то к сложности производительности IO добавляется сложность производительности сети.
Но если нам не нужно все и мы хотим условно "apt-get install nfs" и с этим запускаться, то в базовом варианте NFS в большинстве случаев (есть исключения) будет быстрее по IO чем CephFS, запущенная на этой же одной ноде с этим же количеством дисков.
Но одновременно с этим, NFS нельзя будет масштабировать ни по (общей) производительности ни по объему, поставив рядом еще один/два/три/пять серверов. Ну и само-собой отказоусточивость и доступность нужно как-то самостоятельно гарантировать.
Это сильно натянутое заключение.
Мы получаем 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), станет ясно имеет ли смысл нагружать его. Пока же можно просто модифицировать регэксы.
Пожалуйста, если найдете какие странности/проблемы, не стесняйтесь создавать таску на гитхабе ;)
Когда гуглил что эта штука может отправлять выяснилось что протокол у них всех весьма схожий :)