Search
Write a publication
Pull to refresh
12
0
Dmitry Kireev @AutomationD

SRE and DevOps

Send message

Да никакой. Зато в телеграм паспорте все данные "надежно защищены", поэтому удобно что можно найти не только скан паспорта а еще много другой полезной информации.

А с Телеграм Паспорт можно будет их купить гораздо более удобным способом...

Калифорния. Отпуск в среднем 10 дней в год в стартапах. В крупных компаниях чуть побольше. Отпуска копятся. Но не копить отпуска это ведь не плохо, отдых важен.
Я вот за 2 года в сумме официально отдыхал дней 15...

Эх, Калифорния — это типа 12 недель без оплаты на рождение ребенка...

Мне всегда казалось это именно шаблон речи темнокожих — Ain't no body got time for that, итд.
Когда были в Новом Орлеане — это было заметно особенно сильно!

Не для вреда, а теоретической возможности:
Как насчет перехвата пакетов сильно бушующих точек и переадресации их на github док?) все ответные пакеты от 80 портов просто MITMом заменять на 301/302 redirect. Звучит ведь вполне реально.
Создадим софтик для rpi, список wifi девайсов. Заливай, вставляй и готово!

Ну я к тому, что, во-первых нужно знать какой алгоритм используется для сжатия перед загрузкой, далее какая оптимизация происходит на серверах кеширования итд. ведь часто бывает jpg-> webp или другие связки. Например, как сделать end2end таким образом в facebook?

Как бороться с неподконтрольной компрессией в данном случае?

А еще есть goodsync который для Linux вроде неплохо работает.

Обалденно, прочитал на одном дыхании!
Кстати, в ИТ вроде когда внутренний стандарт SLA становится OLA.

Какое отношение имеет gobot.io к запуску go на embeded? Такое же что и artoo.io cylonjs.com, или я ошибаюсь?

  • Docker на Alpine Linux туда же.

Мода есть, бесспорно. Думаю что приходит из Штатов, в основном, где это является огромным пунктиком. Но изначально, видимо, это происходит из-за каких-то процессов обратным этим. К примеру, шаблонным гендерным высказываниям бывшего CEO убера итд…
Но это только ИМХО и предположение.


А что такое, как Вы выразились, "выпячивание" в русскоязычном интернете воспринимается несколько особенно — само по себе интересное явление :)

<юмор>А мне казалось Windows XP уже "EOL"</юмор>

Спасибо за статью.
Осмелюсь предложить попробовать упростить предложения длиной в абзац (причастные/деепричастные обороты, ИМХО, уменьшают удобство чтения). Также добавьте структуру а-ля "проблема-варианты развития-рассуждения-выводы", ввести заголовки которые обозначают эту структуру.
Ни в коем случае не претендую на звание профи-корректора или стилиста.

Думаю вцелом мы говорим об одном и том же. И Вы правы — это более-менее упрощает независимую конфигурацию репликасета, но на сколько можно упростить конфигурацию шардинга?

А еще удобно роутер запихнуть на клиент, тогда вообще кластер полностью энкапсулируется!

Да, на сколько помню все будет ок. Главное делать на primary. А реплика должна синхронизировать.
По поводу назначения мастера, да, это происходит лучше чем в MySQL. Но мы должны изначально задать Primary. Нельзя взять 3 пустых сервера и обезличенно развернуть. Голосование — да, работает вполне стабильно.
Разворачивать приходится все, я выбрал вариант Ansible, но раздражает что нужно решать кто primary. А дальше — съем бекапов (откуда? — как мы узнаем о том, кто primary а кто нет? — нужен тогда always-secondary? ). При включённом шардинге можно использовать mongos на самом сервере съёма бекаров. Работает ок. Но тогда гемор с воссоединением частей кластера ещё выше. короче хочу чтобы было master-master sharding/replication как в Elsstic Search, чтобы можно указать на члена кластерам и все работало само. Ведь, как видно сегодня, это возможно.

По набору инструментов — да, это тот самый MMS о котором я говорил. Это отдельный облачный продукт (не плохой). Но о чем я пытался сказать что это выглядит несколько низковато выносить такие вещи в платные продукты.

А представьте когда у вас десятки или сотни нод в кластере. А представьте когда на каждом сервере может быть по несколько инстансов монги (потому что оптимизируем диск под запись). А представьте когда волатильность кластера высокая (ноды приходят и уходят).


Да, верно, можно вспомнить про управление конфигурациями, но оно в данной ситуации выглядит для меня немного в качестве костыля, в то время как в мире других БД с кластеризацией / шардингом все гораздо более автоматизировано из коробки.


Автоматический, например, используя unicast / multicast. Задал имя кластера и все.
Или, например, используя механизмы service discovery, когда задаешь адрес сервиса где содержиться информация о кластере.


Плюс возможность выбирать мастера через кворум, можно сказать, стандарт в распределенных системах. В монге мaster/slave выбирается тоже кворумом после фелов,, но мастера обязаны назначить мы. Таким образом подход "cattle" превращается в "pets".


Это мои реалии. Но все же, давайте попробуем рассудить, может мои представления о кластеризации не реалистичны?

Information

Rating
Does not participate
Location
Los Angeles, California, США
Date of birth
Registered
Activity