Если направлять разный трафик на разные машины, то вам понадобится 2 или больше машин вместо 1. 2 и более машин дороже в 2 и более раз, чем 1, потребляют электричества больше чем 1 и занимают в 2 и более раз больше места в датацентре. Это может быть неважно, если продакшен состоит из 1 машины, но если из тысячи, то уже важно иметь 1 тысячу машин, а не 2.
Если же направлять прод и нонпрод трафик в разные контейнеры, расположенные на 1 машине ( а если контейнеров больше чем машин, то это произойдет даже в кубере ), то в момент, когда нонпрод контейнер нагрузит сетевую карту, прод контейнер ( low latency, оно же задача с низкой задержкой ) будет работать с более высокими задержками ( в обоих статьях есть иллюстрирующие графики с задержками с серверов продакшена ), что опять же может быть неважно, если на контейнер приходят 1, 2 и даже 3 запроса в день, но становится важным, когда прод контейнер должен обслуживать тысячи запросов в секунду, тк увеличение задержки обслуживания запросов выше его SLA приведет к отказу в обслуживании. Опять же, в этом случае можно скалировать такой контейнер в 2 и более раз, заняв больше машин в 2 и более раз, но - см 1 абзац.
Нужно еще больше BPF! Мы бы хотели иметь возможность расширять и функционал дискового шедулера - текущие реализации тоже имеют места, которые хотелось бы улучшить.
Возможно, вы снова переносите свои предпочтения на весь мир. В мире есть очень много Java, значительно больше Golang.
Вот тут есть рейтинг популярности языков программирования TIOBE Index, Java более 20 лет занимает 1 и 2 позиции. Это значит, что есть множество программ разработанных на этом языке и их кто то эксплуатирует. Golang стал более менее заметен только с 2017 года и до сих пор не дотянул не то что до Java, но даже и до Visual Basic.
Так что нет, Java более знакома в эксплуатации и возможно именно поэтому имеет большое количество средств диагностики, мониторинга и настройки, которых в Golang просто нет — неуспели сделать. Это разнообразие видимо и дает ощущение сложности.
Но я бы предпочел эксплуатировать критическую часть инфраструктуры имея в своем арсенале все эти инструменты.
Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как необходимо работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее. Kubernetes с Golang в этом плане проще.
Данное утверждение показывает только личные предпочтения автора.
Думаю для восстановления баланса во Вселенной стоит оставить оставить тут такой текст:
К тому же дальнейшее администрирование Kubernetes сложнее по сравнению с Mesos, так как необходимо составлять многостраничные манифесты, работать с etcd, уметь администрировать Golang и быть готовым к связанным с этим трудностям: утечкам памяти, сегфолтам, лимитам и так далее. Mesos с Java в этом плане проще.
Я к тому, что особенности администрирования есть в любой из этих систем, особенно когда их размер достигает десятков тысяч узлов и сводить это к holywar о языках реализации не стоит.
нет, не только под чаты. подойдет ли под ваш конкретный кейс — надо немного больше информации ;-)
в конце статьи последние 2 ссылки ссылки на доклады по другим системам, построенным по этому паттерну.
Еще вот такой есть про классы Класс! ная Cassandra — тоже построен как stateful service
в статье приведена ссылка на исследования группы из google и stanford там есть графики, методики измерений и вот это все. у нас цифры с ними очень похожие. почитайте. они конечно не менеджеры/архитекторы, но вполне неглупые люди.
то, что у вас эти потери составляют 1-2 процента, говорит либо о том, что вы не мерили, либо о том что у вас нет опыта работы с достаточно нагруженными системами, в которых это становится заметным. если же у вас есть исследования, подкрепляющие ваши утверждения — не поленитесь дать ссылку — будет интересно почитать.
Поддержка этого решения на порядки проще, так как инстанс БД, кеши и все остальное работает прямо в приложении и вы можете отладчиком или профилировщиком совершенно спокойно дойти от прикладной логики до движка БД и посмотреть что там происходит. Чем мы и пользуемся для того, чтобы понять что происходит, почему и как это фиксить.
В случае с микросервисом без состояния кластера кешей и БД работают отдельно и вызов профилировщика, на БД например, покажет меньше — все стек трейсы будут одинаковы: сеть -> диспетчер запросов -> выполнение. Часть, связанная с прикладной логикой не видна; ответ на вопрос какой запрос вызывает, допустим, перегрузку — требует отдельного расследования, с помощью своих средств БД, если они там есть, или гаданий на кофейной гуще, если нет или они недостаточны для определения проблемы.
Данные за последние 10 лет мы безвозвратно не теряли ни в одном из более сотни кластеров, в том числе и в результате массовых аварий и пожаров. Раздел «Эксплуатация» во многом посвящен тому как не потерять данные.
Данных в статье я привел довольно много. Каких данных вам не хватает?
На данный момент 288 инстансов, по 96 в ДЦ. Чем мельче инстанс тем быстрее он двигается по инфраструктура/восстанавливается в случае потерь данных и т.п.
Для управления используется one-cloud
Не, немного не так. Основные идеи тут — совмещение БД и кеша с прикладной логикой сервиса. При этом кеш — специализированный, то есть затачивается под приложение.
Все названное тобой — достаточно универсальные идеи, существующие в любой распределенной системе. Возможно, можно это сделать и на Akka — но мне кажется, что это будет избыточным. Может и будет иметь какой то смысл, если Akka уже используется — в противном случае, думаю скорее наоборот — все усложнит и замедлит.
P.S. аватарка мелкая — тыкать надо чтобы разглядеть ;-).
да, пока отрабатывается pagefault кернелом JVM ждет его завершения и на safepoint не становится. соотвественно длительность такой паузы сильно зависит от того какие диски и как хорошо справляется кернел с текущей нагрузкой на чтение/запись.
этот тикет оставлят неясное впечатлениие. насколько я понял прочитанное, разработчики graal не признали проблем с его производительностью.
тот пример долгого старта, что там указан, больше похож на запуск с недостаточным количеством памяти — для jvm в таком случае характерно пытаться непрерывно собирать мусор, что практически почти останавливает выполнение любой программы. На это часто напарываются начинающие пользователи JVM. Для пользователя, конечно, было бы удобнее увидеть нормальное сообщение, что не хватает памяти — но это больше вопрос не к graal, а к эргономике JVM.
Посылка, что мы используем кассандру как одну огромную БД ложна.
Как раз недавно я рассказывал о нашем способе построения систем на основе C*.
Видео про это с Joker 2019 можно посмотреть тут: www.youtube.com/watch?v=x9tvJjWCrr4
Напомню, что часть данных Cassandra хранит в памяти. Чтобы сделать полный бэкап, нужно данные из памяти (Memtables) перенести на диск (SSTables). В этот момент узел Cassandra перестает принимать соединения, полностью выключаясь из работы кластера.
это не так, возможно вы делаете что то не то. ни nodetool flush ( сброс memtables на диск ) ни nodetool snapshot (что есть сброс на диск + создание хардлинков на текущее состоянии данных на диске ) не вызывают остановку ноды кассандры.
возможно, вы пытаетесь сделать nodetool drain, что есть flush + остановка сетевых сервисов ноды кассандры. но для целей бакапа это бессмысленно.
обычно nodetool snapshot и перемещение получившихся хардлинков из поддиректорий snapshots должно быть достаточно для бакапа и последующего восстановления ( если нода в которую идет восстановление имеет тот же ip ).
Такое решение было бы экономически неэффективным. В кассандрах сейчас хранится более 100PB данных в более чем 1000 нод. По такой схеме нам бы пришлось доставить еще грубо 1 или 2 тысячи нод.
Мы сейчас смотрим больше в сторону полной автоматизации замены сбойных нод — что позволит снизить время недоступности оных изза отказа железа. Временная репликация тоже выглядит многообещающе, будем пробовать внедрять.
Конкретно же с этим случаем, отказавший сервис не должен был влиять на доступность логина, это было ошибочное поведение.
Сервисы, связанные с доступностью логина и другими критическими функциями резервируются у нас обычно с RF=5 вместо 3.
Это внутренняя разработка. Про нее подробной информации не было в публичном пространстве, я рассказывал пару слайдов на техтрейне в прошлом году.
Можно послушать например тут: youtu.be/zfmwd52VuQ0?t=2313
Если направлять разный трафик на разные машины, то вам понадобится 2 или больше машин вместо 1. 2 и более машин дороже в 2 и более раз, чем 1, потребляют электричества больше чем 1 и занимают в 2 и более раз больше места в датацентре. Это может быть неважно, если продакшен состоит из 1 машины, но если из тысячи, то уже важно иметь 1 тысячу машин, а не 2.
Если же направлять прод и нонпрод трафик в разные контейнеры, расположенные на 1 машине ( а если контейнеров больше чем машин, то это произойдет даже в кубере ), то в момент, когда нонпрод контейнер нагрузит сетевую карту, прод контейнер ( low latency, оно же задача с низкой задержкой ) будет работать с более высокими задержками ( в обоих статьях есть иллюстрирующие графики с задержками с серверов продакшена ), что опять же может быть неважно, если на контейнер приходят 1, 2 и даже 3 запроса в день, но становится важным, когда прод контейнер должен обслуживать тысячи запросов в секунду, тк увеличение задержки обслуживания запросов выше его SLA приведет к отказу в обслуживании. Опять же, в этом случае можно скалировать такой контейнер в 2 и более раз, заняв больше машин в 2 и более раз, но - см 1 абзац.
Нужно еще больше BPF! Мы бы хотели иметь возможность расширять и функционал дискового шедулера - текущие реализации тоже имеют места, которые хотелось бы улучшить.
вам стоит прочитать предыдущую статью статью про one-cloud тут, там есть ответы на эти вопросы. дублировать ее в комментах думаю не стоит.
Вот тут есть рейтинг популярности языков программирования TIOBE Index, Java более 20 лет занимает 1 и 2 позиции. Это значит, что есть множество программ разработанных на этом языке и их кто то эксплуатирует. Golang стал более менее заметен только с 2017 года и до сих пор не дотянул не то что до Java, но даже и до Visual Basic.
Так что нет, Java более знакома в эксплуатации и возможно именно поэтому имеет большое количество средств диагностики, мониторинга и настройки, которых в Golang просто нет — неуспели сделать. Это разнообразие видимо и дает ощущение сложности.
Но я бы предпочел эксплуатировать критическую часть инфраструктуры имея в своем арсенале все эти инструменты.
Данное утверждение показывает только личные предпочтения автора.
Думаю для восстановления баланса во Вселенной стоит оставить оставить тут такой текст:
Я к тому, что особенности администрирования есть в любой из этих систем, особенно когда их размер достигает десятков тысяч узлов и сводить это к holywar о языках реализации не стоит.
в конце статьи последние 2 ссылки ссылки на доклады по другим системам, построенным по этому паттерну.
Еще вот такой есть про классы Класс! ная Cassandra — тоже построен как stateful service
то, что у вас эти потери составляют 1-2 процента, говорит либо о том, что вы не мерили, либо о том что у вас нет опыта работы с достаточно нагруженными системами, в которых это становится заметным. если же у вас есть исследования, подкрепляющие ваши утверждения — не поленитесь дать ссылку — будет интересно почитать.
Поддержка этого решения на порядки проще, так как инстанс БД, кеши и все остальное работает прямо в приложении и вы можете отладчиком или профилировщиком совершенно спокойно дойти от прикладной логики до движка БД и посмотреть что там происходит. Чем мы и пользуемся для того, чтобы понять что происходит, почему и как это фиксить.
В случае с микросервисом без состояния кластера кешей и БД работают отдельно и вызов профилировщика, на БД например, покажет меньше — все стек трейсы будут одинаковы: сеть -> диспетчер запросов -> выполнение. Часть, связанная с прикладной логикой не видна; ответ на вопрос какой запрос вызывает, допустим, перегрузку — требует отдельного расследования, с помощью своих средств БД, если они там есть, или гаданий на кофейной гуще, если нет или они недостаточны для определения проблемы.
Данные за последние 10 лет мы безвозвратно не теряли ни в одном из более сотни кластеров, в том числе и в результате массовых аварий и пожаров. Раздел «Эксплуатация» во многом посвящен тому как не потерять данные.
Данных в статье я привел довольно много. Каких данных вам не хватает?
Для управления используется one-cloud
Все названное тобой — достаточно универсальные идеи, существующие в любой распределенной системе. Возможно, можно это сделать и на Akka — но мне кажется, что это будет избыточным. Может и будет иметь какой то смысл, если Akka уже используется — в противном случае, думаю скорее наоборот — все усложнит и замедлит.
P.S. аватарка мелкая — тыкать надо чтобы разглядеть ;-).
тот пример долгого старта, что там указан, больше похож на запуск с недостаточным количеством памяти — для jvm в таком случае характерно пытаться непрерывно собирать мусор, что практически почти останавливает выполнение любой программы. На это часто напарываются начинающие пользователи JVM. Для пользователя, конечно, было бы удобнее увидеть нормальное сообщение, что не хватает памяти — но это больше вопрос не к graal, а к эргономике JVM.
Как раз недавно я рассказывал о нашем способе построения систем на основе C*.
Видео про это с Joker 2019 можно посмотреть тут: www.youtube.com/watch?v=x9tvJjWCrr4
это не так, возможно вы делаете что то не то. ни nodetool flush ( сброс memtables на диск ) ни nodetool snapshot (что есть сброс на диск + создание хардлинков на текущее состоянии данных на диске ) не вызывают остановку ноды кассандры.
возможно, вы пытаетесь сделать nodetool drain, что есть flush + остановка сетевых сервисов ноды кассандры. но для целей бакапа это бессмысленно.
обычно nodetool snapshot и перемещение получившихся хардлинков из поддиректорий snapshots должно быть достаточно для бакапа и последующего восстановления ( если нода в которую идет восстановление имеет тот же ip ).
Мы сейчас смотрим больше в сторону полной автоматизации замены сбойных нод — что позволит снизить время недоступности оных изза отказа железа. Временная репликация тоже выглядит многообещающе, будем пробовать внедрять.
Конкретно же с этим случаем, отказавший сервис не должен был влиять на доступность логина, это было ошибочное поведение.
Сервисы, связанные с доступностью логина и другими критическими функциями резервируются у нас обычно с RF=5 вместо 3.
Можно послушать например тут: youtu.be/zfmwd52VuQ0?t=2313