Scrub — это процесс фоновой проверки консистентности данных в Ceph. Он позволяет выявить и устранить несоответствия в копиях, а также найти рассыпающиеся диски, чтобы вовремя их заменить. При этом сам Scrub может создавать высокую нагрузку на кластер и мешать другим процессам. Сегодня расскажем о настройках, которые помогут оптимизировать его работу и сделать нагрузку практически незаметной.

В процессе настройки нового кластера на Ceph Luminous появилась задача разнести разные S3 бакеты по разным устройствам хранения (в моем случае SSD и HDD). В интернете много инструкций как это сделать в Ceph Jewel, но в случае с Luminous процесс претерпел большие изменения и старые инструкции больше не работают. Вместе с тем, что в офф документации этот сценарий не описан, процесс настройки становится не слишком тривиальным.

Англоязычный оригинал опубликован в форуме ixsystems и вряд ли широко известен всем, кто может столкнуться с проблемой. Хотя оригинал датирован 16 апреля 2020, он ссылается в том числе на более поздние публикации, то есть обновлялся.

Жесткие диски, которые записывают данные в перекрывающихся,

upd: Отличный разбор про устройство современного стэка IPsec протоколов ESPv3 и IKEv2 опубликовал stargrave2. Рекомендую почитать.

Linux: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

• Eth0 1.1.1.1/32 внешний IP
• ipip-ipsec0 192.168.0.1/30 будет наш туннель

Mikrotik: CCR 1009, RouterOS 6.46.5

• Eth0 10.0.0.2/30 внутренний IP от провайдера. Внешний IP NAT провайдера динамический.
• ipip-ipsec0 192.168.0.2/30 будет наш туннель

TL;DR В этот статье мы установим single sign-on для SSH от Google. За кулисами мы воспользуемся OpenID Connect (OICD), краткосрочными SSH сертификатами, несколькими хитростями конфигурации SSH, и опенсорсными пакетами step-ca и step от Smallstep. Мы настроим SSH Certificate Authority и воспользуемся им, чтобы загрузить в нашей системе нового пользователя и новый хост. Этот метод привносит много преимуществ помимо single sign-on, так как отпадает нужда в сборе, передаче и контроле файлов authorized_keys, хоть и требует больше подготовительной работы по сравнению с настройкой типичной пары открытого/секретного SSH ключей.

Как не следует пользоваться SSH

Еще в далеком 2004 году кто-то научил меня копипастить открытый ключ в файл authorized_keys. С тех пор я продолжал невинно копировать один и тот же старый публичный ключ на каждый сервер, с которым мне приходилось работать, и у меня постоянно не получалось сделать это с первого раза, потому что я забывал корректно настраивать chmod.

Привет, Geektimes!

Управление мощными нагрузками — достаточно популярная тема среди людей, так или иначе касающихся автоматизации дома, причём в общем-то независимо от платформы: будь то Arduino, Rapsberry Pi, Unwired One или иная платформа, включать-выключать ей какой-нибудь обогреватель, котёл или канальный вентилятор рано или поздно приходится.

Традиционная дилемма здесь — чем, собственно, коммутировать. Как убедились многие на своём печальном опыте, китайские реле не обладают должной надёжностью — при коммутации мощной индуктивной нагрузки контакты сильно искрят, и в один прекрасный момент могут попросту залипнуть. Приходится ставить два реле — второе для подстраховки на размыкание.

Вместо реле можно поставить симистор или твердотельное реле (по сути, тот же тиристор или полевик со схемой управления логическим сигналом и опторазвязкой в одном корпусе), но у них другой минус — они греются. Соответственно, нужен радиатор, что увеличивает габариты конструкции.



Я же хочу рассказать про простую и довольно очевидную, но при этом редко встречающуюся схему, умеющую вот такое:

• Гальваническая развязка входа и нагрузки
• Коммутация индуктивных нагрузок без выбросов тока и напряжения
• Отсутствие значимого тепловыделения даже на максимальной мощности

Но сначала — чуть-чуть иллюстраций. Во всех случаях использовались реле TTI серий TRJ и TRIL, а в качестве нагрузки — пылесос мощностью 650 Вт.

Есть ли среди нас (цефоводов) те, кто не любит «профессиональный экстрим»?

Вряд ли — иначе бы мы не кувыркались с этим чрезвычайно интересным и забавным продуктом.

Многие из тех, кто занимались эксплуатацией Ceph, встречали один не слишком частый (а скорее даже очень нечастый) но иногда востребованный кейс — подключить Ceph по iSCSI или FC. Зачем? Ну, например, подать образ с Ceph на почему-то еще не виртуализированный сервер Windows или Solaris. Или на виртуализированный, но посредством гипервизора, который не умеет Ceph — а их, как мы знаем, хватает. Например? Ну, например, HyperV или ESXi, которые активно используются. И если возникает задача подать образ с Ceph в гостевую машину, это превращается в весьма увлекательную задачу.

Выбор CEPH. Часть 1

У нас было пять стоек, десять оптических свичей, настроенный BGP, пару десятков SSD и куча SAS дисков всех цветов и размеров, а ещё proxmox и желание засунуть всю статику в собственное S3 хранилище. Не то чтобы это всё было нужно для виртуализации, но раз начал использовать opensource — то иди в своём увлечении до конца. Единственное, что меня беспокоило — это BGP. В мире нет никого более беспомощного, безответственного и безнравственного, чем внутренняя маршртутизация по BGP. И я знал, что довольно скоро мы в это окунёмся.

Задача стояла банальная — имелся CEPH, работал не очень хорошо. Надо было сделать "хорошо".
Доставшийся мне кластер был разнородным, настроенным на скорую руку и практически не тюнингованным. Он состоял из двух групп разных нод, с одной общей сеткой выполняющей роль как cluster так и public network. Ноды были набиты четырьмя типами дисков — два типа SSD, собранными в два отдельных placement rule и два типа HDD разного размера, собранными в третью группу. Проблема с разными размерами была решена разными весами OSD.

Саму настройку разделили на две части — тюнинг операционной системы и тюнинг самого CEPH и его настроек.

Ceph — это object storage, призванный помочь построить отказоустойчивый кластер. И все-таки отказы случаются. Все, кто работает с Ceph, знают легенду о CloudMouse или Росреестре. К сожалению, делиться отрицательным опытом у нас не принято, причины провалов чаще всего замалчивают, и не дают будущим поколениям научиться на чужих ошибках.

Что ж, настроим тестовый, но близкий к реальному кластер и разберем катастрофу по косточкам. Измерим все просадки производительности, найдем утечки памяти, разберем процесс восстановления обслуживания. И все это под руководством Артемия Капитулы, который потратив почти год на изучение подводных камней, заставил при отказе производительность кластера не падать в ноль, и latency не подскакивать до неприличных значений. И получил красный график, который ну сильно лучше.


Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.

Есть у нас веб-приложение. Относительно большое и старое — много-много кода, в котором много-много разных запросов к базе данных. При этом мы не гугл, но несколько тысяч запросов в секунду на сервер БД приходится.

Ну и безусловно растёт наше приложение во все стороны — добавляются новые фичи, наворачиваются и усложняются старые, растёт количество клиентов и соответственно количество данных в БД. И в один не очень прекрасный момент приходит понимание, что что-то наше приложение тормозит. А значит надо или найти, что именно нагружает БД, хотя могло бы не нагружать, ну или если ничего такого нет, то взять ещё серверов побольше, да помощнее.

Стандартный совет как найти, что нагружает MySQL — включить slow-query-log и посмотреть, какие запросы будут туда попадать. Но в MySQL 5.7 по умолчанию присутствует куда лучший инструмент — sys schema, которая агрегирует данные из performance schema и позволяет их получить простыми запросами, буквально вида «Ok, MySQL, покажи мне топ запросов по максимальному суммарному времени выполнения»

Всем привет!

Как-то раз появилась по работе задача — есть вроде бы настроенный тестовый innoDB cluster на нескольких виртуалках с centos 7.5, надо его поизучать и добавить еще пару нод. Можно ломать и издеваться как угодно. Звучит заманчиво.

Думаю, что по скриншоту уже понятно, о чём идёт речь. Но, дабы не дублировать текст, который уже описан в документации, я расскажу только о важных моментах.

Добрый день. В этой небольшой заметке я хочу рассказать как быстро и просто настроить push-уведомления на вашем сайте. Эта статья ни в коем случае не претендует на звание исчерпывающего руководства, но, я надеюсь, что она даст точку старта для дальнейшего изучения.

Информации по этой теме в интернете полно, но она фрагментирована, разбросана по разным ресурсам и перемешена с уведомлениями для мобильных устройств с примерами на Java, C++ и Python. Нас же, как веб-разработчиков, интересует JavaScript. В этой статье я постараюсь саккумулировать всю необходимую и полезную информацию.

Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.

Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.

Предистория

Одним прекрасным днём мне понадобилось развернуть среду разработки для своего проекта. Vagrant уже порядком поднадоел и хотелось иметь единую среду разработки для всех участников проекта которая была бы идентичной production серверу. Соответственно наслушавшись информации про хипстерский docker, я решил начать с ним разбираться. Далее я постараюсь максимально подробно описать все шаги начиная от установки докера на локалке вплоть до разворачивания продуктива на KVM.

Исходный стек технологий:

— Docker
— Symfony 4
— nginx
— php-fpm
— postgresql
— elasticsearch
— rabbitmq
— jenkins

Железо:

— ноутбук под ОС Ubuntu 16.04
— продакшн сервер на хостинге KVM

Почему кроме технологического стека я перечислил ещё и стек железа?

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

Первый и наверно самый важный аспект при начале работы с докером — это операционная система вашего ноутбука. Проще всего работать с докером именно на linux системах. Если вы работаете на Windows или Mac то у вас 100 % будут некоторые сложности, но эти сложности не будут являться критическими и при желании «нагуглить» как это исправляется не составит никаких проблем.

Второй вопрос — это хостинг. Зачем нужен Hosting именно с типом виртуализации KVM? Причина в том, что виртуализация VPS разительно отличается от KVM и установить сам docker на VPS у вас попросту не выйдет, так как VPS распределяет ресурсы сервера динамически.

Подитог: для самого быстрого старта на докере резоннее всего выбирать Ubuntu в качестве локальной операционки и KVM хостинг (либо собственный сервер). Далее рассказ пойдёт опираясь именно на эти две составляющие.

В этой статье я расскажу о том, как устроен и развивался сервис по поиску объявлений жилья из Вконтакте, почему была выбрана сервис-ориентированная архитектура, а также какие технологии и решения использовались при его разработке.

С приобретением нового телевизора возник вопрос, какую приставку для него брать. Возможностей Chromecast уже не хватало и хотелось полноценный медиацентр на Kodi. Телевизор со SmartTV покупать не вариант — Kodi можно установить только на Android (из SmartTV платформ), а к нему я отношусь без особой любви, к тому же он уже внутри телевизора, а не в отдельной коробке, которую можно безбоязненно перепрошивать. Ну а зачем мне полноразмерный Android, со всеми его сервисами и программами в виртуальной машине, без полноценного GNU/Linux окружения и, скорее всего, без обновлений? По той же причине также были отметены многочисленные готовые медиацентры на Android, хотя та же приставка от Xiaomi довольно хороша. Можно было бы подумать насчёт SmartTV на TizenOS, но для него нет Kodi.

Распространенность оборудования Mikrotik растет с каждым днем, все больше устройств, а значит и RoS, появляется не только в корпоративном секторе, но и у обычных, домашних пользователей.
К сожалению, не смотря на вполне нормальные настройки по умолчанию, которые можно сделать через Quick Set, в интернете можно встретить множество советов очистить конфигурацию, и сделать как-то по «особому», с «нуля». В этой статье я хочу поделится своим опытом и дать рекомендации, как изменить конфигурацию из Quick Set под свои нужды, при этом сохранив достаточный уровень защищенности.

Всем привет. Это моя юбилейная статья на Хабре. За почти 7 лет я написал 10 статей (включая эту), 8 из них — технические. Общее количество просмотров всех статей — около полумиллиона.
Основной вклад я внёс в два хаба: PHP и Серверное администрирование. Мне нравится работать на стыке этих двух областей, но сфера моих интересов гораздо шире.

Как и многие разработчики я часто пользуюсь результатами чужого труда (статьи на Хабре, код на гитхабе, ...), поэтому я всегда рад делиться с сообществом своими результатами в ответ. Написание статей — это не только возврат долга сообществу, но так же позволяет найти единомышленников, получить комментарии от профессионалов в узкой сфере и ещё больше углубить свои знания в исследуемой области.

Собственно эта статья об одном из таких моментов. В ней я опишу чем занимался почти всё своё свободное время за последние полгода. Кроме тех моментов, когда я ходил купаться в море через дорогу, смотрел сериалы или игрался в игры.

Наконец-то дождались, после пристального рассматривания и реверс инжениринга протокола MTProto Proxy, Telegram решил выпустить официальный вариант, с поддержкой монетизации promoted каналов, да еще и сразу в Docker образе.

Сразу после событий с блокировками Telegram в Иране и России, в бета-версиях мессенджера начал появлятся новый тип Proxy, а если быть точным, новый протокол — MTProto Proxy.

Этот протокол был создан командой Telegram для решения проблем обхода блокировок, но так ли он хорош?