Сегодня мы будем делать зарядное устройство для электромобиля по давно забытой дендрофекальной технологии.
Просьба убрать от экранов детей, беременных женщин и людей, серьёзно занимающихся электроникой - может хватить удар.
Новгородов Игорь @blind_oracle
Инженер, разработчик
Cortex и не только: распределённый Prometheus
17 min
Tutorial
В последнее время Prometheus стал де-факто стандартом для сбора и хранения метрик. Он удобен для разработчиков ПО - экспорт метрик можно реализовать в несколько строк кода. Для DevOps/SRE, в свою очередь, есть простой язык PromQL для получения метрик из хранилища и их визуализации в той же Grafana.
Но Prometheus имеет ряд недостатков, способы устранения которых я хочу рассмотреть в этой статье. Также разберём деплой Cortex.
Обход блокировок РКН с помощью DNSTap и BGP
10 min
Tutorial
Тема довольно изъезжена, знаю. К примеру, есть отличная статья, но там рассматривается только IP-часть блоклиста. Мы же добавим еще и домены.
В связи с тем, что суды и РКН блокируют всё направо и налево, а провайдеры усиленно пытаются не попасть под штрафы, выписанные "Ревизорро" — сопутствующие потери от блокировок довольно велики. Да и среди "правомерно" заблокированных сайтов много полезных (привет, rutracker)
Я живу вне юрисдикции РКН, но на родине остались родители, родственники и друзья. Так что было решено придумать легкий для далеких от ИТ личностей способ обхода блокировок, желательно вовсе без их участия.
В этой заметке я не буду расписывать базовые сетевые вещи по шагам, а опишу общие принципы как можно реализовать эту схему. Так что знания как работает сеть вообще и в Linux в частности — must have.
Путеводитель по Швейцарии
42 min
Приветствую, товарищи!
В этой статье я постараюсь описать свой опыт переезда в замечательную альпийскую страну Швейцарию, а конкретно — в город Цюрих, и рассказать о наиболее важных аспектах жизни здесь.
Пост будет очень объемный, потому что я хотел сделать эдакий мини-гайд по жизни в Швейцарии, по которому потенциальный тракторист сможет оценить страну. А тем, кто уже тут или собирается в ближайшее время, статья может помочь разобраться с местными особенностями — не всегда можно легко найти ответы на вопросы, особенно не зная язык.
Я решил не делить его на отдельные куски — так информацию искать будет проще. Надеюсь что не сильно нарушу тематику ресурса, пусть НЛО нас рассудит.
Flumserberg. Здесь и далее — обычно мои фотографии, которые мне показались более или менее приличными :)
В этой статье я постараюсь описать свой опыт переезда в замечательную альпийскую страну Швейцарию, а конкретно — в город Цюрих, и рассказать о наиболее важных аспектах жизни здесь.
Пост будет очень объемный, потому что я хотел сделать эдакий мини-гайд по жизни в Швейцарии, по которому потенциальный тракторист сможет оценить страну. А тем, кто уже тут или собирается в ближайшее время, статья может помочь разобраться с местными особенностями — не всегда можно легко найти ответы на вопросы, особенно не зная язык.
Я решил не делить его на отдельные куски — так информацию искать будет проще. Надеюсь что не сильно нарушу тематику ресурса, пусть НЛО нас рассудит.
Flumserberg. Здесь и далее — обычно мои фотографии, которые мне показались более или менее приличными :)
Бюджетное SAN-хранилище на LSI Syncro, часть 2
18 min
Tutorial
Продолжу, первая часть тут.
Кластер
Итак, приступим к настройке софта, управляющего кластером.
У нас это будет Pacemaker + Corosync в качестве транспортного бэкенда для общения между нодами.
Corosync для большей надёжности поддерживает работу через несколько колец обмена данными.
Причём, три и более уже не тянет, хотя в доках про это нигде особо не указано, только ругается при запуске если указать более двух в конфиге.
Кольца названы так потому что общение между нодами идёт по кольцу — ноды передают данные друг другу последовательно, заодно проверяя живучесть друг друга. Работает оно по UDP, может как по мультикасту, так и по уникасту. У нас будет последний, почему — будет понятно ниже.
Кольца
Для связи между нодами я решил применить несколько параноидальную схему — внешнее кольцо через коммутаторы (тут стандартный Bonding/Etherchannel на два свича) + внутреннее кольцо, соединяющее ноды напрямую (напомню, что их три — два хранилища + свидетель).
Схема следующая:
Зелёные связи — внутреннее кольцо, чёрные — внешнее. В данной топологии ноды должны будут сохранить связность даже при полном отказе внешних устройств (шторм положил коммутаторы, админ (то бишь я) своими кривыми руками что-то напортачил… маловероятно, но всё может быть).
Бюджетное SAN-хранилище на LSI Syncro, часть 1
38 min
Tutorial
Вторая часть
Итак, продолжу свои редкие статьи на тему «как не платить HP/EMC/IBM многие кило-(или даже мега-) доллары и собрать своё хранилище не хуже». Прошлый цикл я до победного конца не довёл, но 90% мыслей всё же оформил в текст.
Нашей сегодняшней целью будет отказоустойчивое «All-Flash» (то есть — только из SSD, без жестких дисков, хотя это и не принципиально) хранилище для нужд кластера vSphere, в несколько раз дешевле брендовых аналогов и с очень неплохой производительностью. Подключаться к нему мы будем по Fibre Channel, но никто не мешает сделать iSCSI, FCoE или даже, о ужас, Infiniband.
Syncro
Как ясно из названия, основой всей этой богодельни станет достаточно уникальный на рынке продукт под названием Syncro CS от компании LSI (ныне Avago).
Что же оно такое есть и чем примечательно?
По сути, это комплект из двух обычных контроллеров LSI 9286-8e (либо 9271-8i, если нужны внутренние порты) и двух суперконденсаторов для сохранения кеш-памяти на флешку контроллера в случае потери питания. Стоимость комплекта при этом в несколько раз выше цены аналогичного комплекта без HA-функционала. Но, если сравнивать с решениями на базе DRBD, то эта разница с лихвой компенсируется отсутствием необходимости иметь двойной набор накопителей.
Но самое интересное кроется в прошивке. Благодаря ей, эти контроллеры, будучи подключенными к одной SAS-сети (например, дисковой корзине с экспандерами) устанавливают через неё связь друг с другом и работают в режиме отказоустойчивого кластера.
Для нас это интересно вот чем:
- Возможность создавать RAID-массивы, доступные сразу на двух серверах
- Отказоустойчивость на уровне контроллеров: при смерти одного из них (или целиком сервера) второй продолжит работать и обслуживать I/O
Создание надёжного iSCSI-хранилища на Linux, часть 2
10 min
Tutorial
Часть первая
Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.
В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:
Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.
После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:
Итак, менеджер кластера.
Продолжаем
Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.
В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:
# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.
После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:
# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2
Pacemaker
Итак, менеджер кластера.
Создание надёжного iSCSI-хранилища на Linux, часть 1
11 min
Tutorial
Часть вторая
Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.
Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.
Требования у меня были простые: создать кластер для работы виртуальных машин, не имеющий единой точки отказа. А в качестве бонуса — хранилище должно было уметь шифровать данные, чтобы враги, утащив сервер, до них не добрались.
В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.
Осталось хранилище. Разные брендовые решения от ведущих вендоров были отброшены по причине большой стоимости как их самих по себе, так и лицензий на синхронную репликацию. Значит будем делать сами, заодно и поучимся.
В качестве софта было выбрано:
В итоге, в недолгих муках была рождена такая несложная схема:
Прелюдия
Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.
Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.
Вводные
Требования у меня были простые: создать кластер для работы виртуальных машин, не имеющий единой точки отказа. А в качестве бонуса — хранилище должно было уметь шифровать данные, чтобы враги, утащив сервер, до них не добрались.
В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.
Осталось хранилище. Разные брендовые решения от ведущих вендоров были отброшены по причине большой стоимости как их самих по себе, так и лицензий на синхронную репликацию. Значит будем делать сами, заодно и поучимся.
В качестве софта было выбрано:
- Debian Wheezy + LTS ядро 3.10
- iSCSI-таргет SCST
- DRBD для репликации
- Pacemaker для управления ресурсами кластера и мониторинга
- Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)
В итоге, в недолгих муках была рождена такая несложная схема:
Восстановление прошивки RAID-контроллеров LSI
4 min
Доброго времени суток, хабравчане!
Я хочу рассказать вам о том, как я восстанавливал прошивку RAID-контроллера LSI MegaRAID после неудачного обновления.
Когда эта беда случилась со мной, то информации об этом я практически не нашел, хотя, допускаю, что плохо гуглил.
В своей работе я уже достаточно давно использую серверы Supermicro, так как у них есть большой выбор платформ, достаточно демократичная цена и приличная надежность.
Зачастую, особенно в случае с 1U серверами я беру их уже с интегрированным контроллером LSI MegaRAID.
Но проблема с ними заключается в том, что сама Supermicro не очень охотно выкладывает прошивки для встроенных контроллеров, так что я их обычно прошиваю актуальной прошивкой (масло масляное, да) от аналогичного контроллера LSI. Проблем не возникало до этих пор.
Недавно привезли несколько серверов с контроллерами LSI 2208 на борту и достаточно старой прошивкой.
Т.к. дискретные контроллеры на этих чипах я тоже активно использую, то особо не сомневаясь загрузился с флешки с Linux-ом, запустил привычное:
Когда я в следующий раз обратил взор на терминал сервера, то увидел ту же самую картину, что и была — «Flashing firmware...» и никакого результата. Беда, подумал Штирлиц.
Я хочу рассказать вам о том, как я восстанавливал прошивку RAID-контроллера LSI MegaRAID после неудачного обновления.
Когда эта беда случилась со мной, то информации об этом я практически не нашел, хотя, допускаю, что плохо гуглил.
Анамнез
В своей работе я уже достаточно давно использую серверы Supermicro, так как у них есть большой выбор платформ, достаточно демократичная цена и приличная надежность.
Зачастую, особенно в случае с 1U серверами я беру их уже с интегрированным контроллером LSI MegaRAID.
Но проблема с ними заключается в том, что сама Supermicro не очень охотно выкладывает прошивки для встроенных контроллеров, так что я их обычно прошиваю актуальной прошивкой (масло масляное, да) от аналогичного контроллера LSI. Проблем не возникало до этих пор.
Недавно привезли несколько серверов с контроллерами LSI 2208 на борту и достаточно старой прошивкой.
Т.к. дискретные контроллеры на этих чипах я тоже активно использую, то особо не сомневаясь загрузился с флешки с Linux-ом, запустил привычное:
./MegaCli64 -AdpFwFlash -f mr2208.rom -a0
Когда я в следующий раз обратил взор на терминал сервера, то увидел ту же самую картину, что и была — «Flashing firmware...» и никакого результата. Беда, подумал Штирлиц.