Рубрика: Linux

Еще один пример использования нескольких таблиц маршрутизации

Артур Крюков

Добавил новый материал в раздел Материалы к курсам.

Два провайдера. Правильная конфигурация таблицы маршрутизации.

Или, что следует сделать в первую очередь при подключении двух и более провайдеров к Linux роутеру.

Странное rancher/docker vs LXC

Артур Крюков

Решил попробовать модный в кругах девопсов кубернейт/docker. Самое простое развертывание кластера, как мне показалось — использовать rancher, который ставит кубернейт из «коробки». Да и сам запускается в контейнере docker.

Поставил на двух виртуальных машинах. Собрал, запустил. Запустил внутри приложение WordPress (nginx, php, mariadb). Немного удивился, сколько ресурсов съела эта связка. Давно у меня машинка swap на 100% не кушала. Конечно я еще не настолько влез во внутренности. Но всё же. Последний раз такой жор ресурсов с приложением по умолчанию я видел у 1С ERP 🙂

При этом, на той же самой виртуалке LXC контейнер со всем этим добром работает не напрягаясь. В общем буду разбираться. Придётся еще 16 гигов памяти прикупить 🙂

Добавил LVM в первые шаги

Артур Крюков

Добавил новый материал, посвящённый работе с LVM в «первые шаги» в разделе «Материалы к курсам«.

Это не полное руководство по LVM. В частности там не указана работа со снапшотами, миграция и некоторые другие плюшки. Но данных хватит для начала работы с lvm и понимания его устройства.

Перенёс перевод параметров ядра Linux.

Артур Крюков

Со старого wiki перенёс на этот сайт перевод на русский язык конфигурационных параметров ядра Linux. Дела конечно давние, но судя по статистике, народ регулярно заходит на эти страницы.

Заодно вспомнил какие технологии были 10 лет назад. Прикольно 🙂

Осталось перенести «Курс молодого бойца». Но это очень много информации. Так что старый wiki пока поживёт.

postfix и LDAP

Артур Крюков

Почему мне нравится postfix? Вроде бы sendmail вполне хорошо справляется с обработкой почты. Чем же posfix лучше?

Я предпочитаю хранить информацию о пользователях не в локальных файлах или базах данных типа MySQL, а в LDAP серверах (OpenLDAP, Active Directory и т.п.). И лично для меня решающим фактором перехода с sendmail стало то, как postfix работает с LDAP серверами.

В качестве простого примера можно рассмотреть работу с псевдонимами.

По умолчанию postfix использует всем хорошо знакомый файл /etc/aliases.

alias_maps = hash:/etc/aliases

Но доступ к этому файлу имеет только суперпользователь. Если вы один админ на всю деревню – то особых затруднений это не вызывает. Но если админов несколько? Давать всем пароль root? Вы это серьёзно?

Вот тут то и помогает LDAP, в том числе и возможностью разграничения доступа.

Можно создать ou в котором будут храниться псевдонимы. В текущих схемах OpenLDAP на CentOS я не нашел готовую схему для почтовых псевдонимов. Поэтому для хранения информации о них решил использовать objectClass inetOrgPerson.

У inetOrgPerson три обязательных атрибута: cn, sn и mail. Сn будет использоваться в качестве имени псевдонима и части dn записи. Mail – показывает куда пересылать почту. В простейшем случае в sn можно дублировать информацию из cn.

Например, создадим ou в котором будут храниться псевдонимы:

dn: ou=Aliases,dc=company,dc=ru
objectclass: organizationalUnit
objectclass: top
ou: Aliases

И добавим туда простейший псевдоним:

dn: cn=psevdo,ou=Aliases,dc=company,dc=ru
cn: psevdo
mail: localuser
mail: anotheruser@mail.ru
objectclass: inetOrgPerson
objectclass: top
sn: psevdo

Для того, что бы postfix работал с OpenLDAP следует создать текстовый файл фильтра, например /etc/postfix/ldap_aliases.cf следующего содержания:

# или имя сервера
server_host = 1.2.3.4
# контейнер, где хранятся псевдонимы
search_base = ou=Aliases,dc=company,dc=ru
# искать во всем дереве, начиная с указанного выше контейнера
scope = sub
# запрос к LDAP серверу
query_filter = (&(objectClass=inetOrgPerson)(cn=%u))
# атрибут, который мы должны получить в ответ в результате поиска
result_attribute = mail
# Пользователь, с правами которого мы обращаемся к серверу
bind_dn = cn=proxy user,dc=company,dc=ru
# Пароль этого пользователя
bind_pw = this_is_a_password_proxy_user

В файле main.cf добавляем фильтр поиска:

alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap_aliases.cf

Т.е. у нас остается классический вариант /etc/aliases и к нему добавляется поиск псевдонимов в LDAP сервере.

В дальнейшем разруливаем права доступа в OpenLDAP для админов, пароль root им больше не понадобится.

Кстати, поле sn можно использовать в качестве логического. Для включения выключения псевдонима.

dn: cn=psevdo,ou=Aliases,dc=company,dc=ru
cn: psevdo
mail: localuser
mail: anotheruser@mail.ru
objectclass: inetOrgPerson
objectclass: top
sn: true

Если хотим, что бы псевдоним работал – присваиваем sn значение true. Для отключения – все что угодно кроме true.

Ну и немного изменим query_filter:

query_filter = (&(objectClass=inetOrgPerson)(cn=%u)(sn=true))

Итак мы можем обратиться к LDAP с любым запросом. Попросить вернуть только нужные нам атрибуты. Как такое сделать в sendmail  я не знаю 🙁

Mkrotik и vlan по быстрому.

Артур Крюков

Купили новый маленький роутер от Mikrotik — RB4011iGS+RM. Решили попробовать как он будет работать в маленькой сетке в качестве роутера (странно? Да? 🙂 ). У него есть 10G SFP+ интерфейс, подключенный непосредственно к процессору. Если включить FastPath, то по идее должен справляться.

SFP+ интерфейс естественно в trank. На всякий пожарный eth6, тоже в транк. Eth с 1-го по 5-й в 1-й vlan, в режиме access mode, что бы подключаться прямо в серверной к коммутаторам, если вдруг чего. Остальные не задействованы.

При обращении к Google с вопросом Mirotik+vlan вываливается куча страниц с описанием настройки vlan. Но, проблема в том, что они блин все устарели! В новых версиях router os все уже не так.

Как сейчас рулить vlan с возможностью маршрутизации? Теперь там все через bridge интерфейс.

В первую очередь добавляем сам мост:

> /interface bridge
/interface bridge> add name=core

Добавим к мосту порты, в которых будут бегать тегированные пакеты:

/interface bridge> port
/interface bridge port> add bridge=core interface=sfp-trunk
/interface bridge port> add bridge=core interface=ether6

Порты, работающие в access режиме:

/interface bridge port> add bridge=core interface=ether1
/interface bridge port> add bridge=core interface=ether2
/interface bridge port> add bridge=core interface=ether3
/interface bridge port> add bridge=core interface=ether4
/interface bridge port> add bridge=core interface=ether5

Там же, в разделе bridge есть возможность указывать какие vlan на каком интерфейсе и режим работы интерфейса.

/interface bridge port> /interface bridge vlan
/interface bridge vlan> add bridge=core tagged=sfp-trunk,ether6,core untagged=ether1,ether2,ether3,ether4,ether5 vlan-ids=1
/interface bridge vlan> add bridge=core tagged=sfp-trunk,ether6,core vlan-ids=1010,1011,1254

Итак, мы добавили vlan 1 к нужным нам интерфейсам и заодно определили режимы работы самих интерфейсов. Так же были определены другие vlan, которые будут приходить на mikrotik и в дальнейшем мы будем заниматься маршрутизацией между этими сетями.

На данном этапе пакеты Ethernet начнут бегать в своих vlan.

Пришло время заняться маршрутизацией.

Обязательно добавляйте интерфейс моста в параметре tagget при добавлении vlan в разделе bridge! Без этого у нас ничего не получиться на 3-м уровне 🙁

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

Как обычно, интерфейсы создаём в разделе interface vlan (не bridge vlan!).

> /interface vlan
/interface vlan> add interface=core name=VLAN-1254 vlan-id=1254
/interface vlan> add interface=core name=VLAN-1010 vlan-id=1010
/interface vlan> add interface=core name=VLAN-1011 vlan-id=1011

Обратите внимание, что vlan-ы мы добавляем к bridge интерфейсу core. Не зря мы включали на этом интерфейсе режим работы tagged.

Осталось добавить ip адреса на интерфейсы:

> /ip address
/ip address> add address=192.168.1.1/24 interface=core network=192.168.1.0
/ip address> add address=192.168.10.1.24 interface=VLAN-1010 network=192.168.10.0
/ip address> add address=192.168.11.1/24 interface=VLAN-1011 network=192.168.11.0
/ip address> add address=192.168.254.1/24 interface=VLAN-1254 network=192.168.254.0

Наши админы очень любят DHCP сервер mikrotik, поэтому его тоже придется поднимать на этом устройстве. Поскольку интерфейсы сконфигурированы, DHCP сервер настраивается обычным образом.

Вот и все.

Перевез wiki.

Артур Крюков

Ну вот. Старый хостинг совсем сдох. Даже не успел скачать данные wiki. Слава богу, был бекап годичной давности (а что? информация там давно не менялась).

Получил +4 к уровню nginx. Экспа растёт!

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

lxc, xfs и sguid bit

Артур Крюков
Забавно получилось. Оказывается если разворачивать контейнеры lxc на файловой системе xfs, внутри контейнера перестаёт работать SGID бит. Хорошо, что заметили на этапе тестирования.

Как сэкономить 10 миллионов при размещении рабочих мест пользователей в облаке.

Артур Крюков

У нас есть большое количество пользователей, которым по различным причинам необходимы административные права на своём рабочем компьютере. И это является жесточайшей головной болью IT отдела. Рабочие места в основном стандартные: 1С, офис, браузер, почтовый клиент и некоторый специфичный софт (из-за которого и приходиться давать админ права).
После очередной массовой перезаливки компьютеров возник вопрос: доколе администраторы будут терпеть такое издевательство над своей нервной системой? Посидели, подумали, прикинули возможности персонала, финансовые возможности компании, риски, писки пользователей и решили перенести рабочие станции пользователей в виртуальные машины. А что? Удобно. Сделал снапшот, пользователь накосячил – восстановил из снапшота. Ляпота.

Первый вариант. Ставим виртуальную машину прямо на компьютер пользователя.

Да, это можно сделать. Ставим основной ОС Linux. Зачем покупать ещё одну лицензию Windows? Пользователю Linux не нужны права админа. У него на рабочем столе две иконки: браузер и клиент виртуальной машины. Сама виртуалка запускается как сервис при старте системы.
Вроде нормально, удаленно подключился к машинке, поигрался с снапшотами, все довольны.
Но есть большая проблема: для этой схемы нужно адекватное железо. А у многих наших пользователей стоит дешманский вариант железа. Есть даже машины с XP. Там родная ОС еле ворочается, а уж если её засунуть в виртуалку – всё сдохнет.
Покупать адекватное железо? Тут финансовый отдел мозг вынесет.

Второй вариант. Облако.

Размещать свои машины в облачных сервисах Амазон, Гугл и прочее – не наш метод. Есть множество причин, почему нам это не подходит. Поэтому надо делать свое облако.
Большой плюс: у пользователей можно оставить старое железо с Linux и двумя иконками. Лицензия Windows в большинстве случаев коробочная (так исторически сложилось), поэтому её можно без проблем перенести в виртуалки. Для новых пользователей в качестве рабочих станций можно покупать хоть Расбери ПиАй :).
Минус: надо покупать новые сервера и софт для управления всем этим хозяйством.
Второе решение нам понравилось больше.

Поиск технологии.

В качестве технологии выбрали модное ныне направление гиперконвергентной (во слово то какое выдумали!) виртуализации. У гипер есть много плюсов, расписывать их не буду.
Первоначально рассматривали решение Nutanix, поскольку оно вылазит во всех запросам по поводу гипер, да и после того, как постепенно вникли в тему – прониклись идеями Nutanix. Опять же, судя по блогам и твиттеру Nutanix новым клиентам предоставляет вкусные скидки, дает попробовать оборудование. У них есть решения для мелкого бизнеса. В общем – ляпота. (Забегая вперед скажу – все это маркетинговая шелуха.)
В итоге пришли к такой постановке задачи:
  •         Нужна система с начальной емкостью 50 виртуальных машин по 2 ядра процессора и 4-6 гигов RAM на гостевую систему.
  •         Система будет наращиваться по 10 рабочих машин.
  •         Живая миграция не нужна (но приветствуется).
  •         Лицензии нужно купить сразу или по мере расширения, и никаких новомодных ежегодных подписок.
  •         Система должна занимать минимум места в стойке.

С таким первоначальным запросом обратились к двум официальным дилерам Nutanix: в Москве и Подмосковье.
И… мы не получили от них никакого ответа! Месяц нас кормили завтраками, а потом мы поняли, что нас просто сливают. Наш заказ слишком мелкий? Эй! Nutanix ваши дилеры портят вам бизнес и репутацию!
Тогда мы решили забить на Nutanix и их официальных дилеров и обратиться к крупному интегратору. Тут было совсем другое отношение к клиенту: ответы молниеносные, развернутые с описанием на уровне «покажи руководству – они это смогут понять». Прелестно.
Правда вместо Nutanix нам предложили решение на HPE SimpliVity. (Эй! Nutanix с вами не хотят связываться даже интеграторы). Учитывая наши задачи, мы никогда не достигнем ограничений, которые есть у SimpliVity.

Цена вопроса.

В итоге нампосчитали конфигурацию: 2 сервера SimpliVity, VMw Horizon, Windows Server Datacenter Edition, SQL Server.

Почему Windows Server? Потому что если в виртуалки засовывать Windows 10 и подключаться к ним по RDP нам ежегодно придется покупать соответствующие CAL лицензии для работы с виртуальной машиной. А так одинраз купил CAL лицензию доступа к серверу и не морочишь себе голову.
В стойке такое решение занимает 9U: 2 сервера по 3U и три коммутатора по 1U.
Первоначальные затраты 50 рабочих мест: около 10 000 000 (цены на конец 2017 года). На 200 пользователей (планка к которой мы хотели прийти в результате): 15 500 000 рублей. Без учета стоимости услуг интегратора.
Итого одно рабочее место: 75500 рублей.

И тут мы решили включить мозг!

Цена за рабочее место оказалась гораздо выше стоимости покупки новой машины для пользователя! Первоначальное вложение в систему просто огромное. С такими цифрами к начальству не пойдешь. Ну нет никакого экономического эффекта от внедрения новой технологии. Да и 10 лямов сразу никто никогда нам не даст! Это же целый 600-й мерин в дешманской комплектации! А итоговая система – это почти Майбах! И никак не получиться вливать деньги малыми порциями.
Проще потихоньку покупать новые компьютеры, потихоньку меняя парк устаревших машин. Начальству все равно, что админы загибаются и портят нервы. По его (начальства) мнению – нервы админа входят в получаемую ими заработную плату.
И тут мы решили включить мозги! Интегратор – это хорошо, но они продают выгодные им решения и я это прекрасно понимаю и никаких претензий не предъявляю. А нам надо убрать нашу головную боль так, что бы и боль прошла и начальство не напрягалось.
Первое – нам не нужно большинство фишек, которые предоставляет VMw Horizon. Значит вмваре в топку.
Второе – два мощных сервера. Они были нужны для оптимизации закупки Windows Server. Дешевле получалось купить два очень мощных сервера, чем 10 не очень мощных. Поэтому в топку пошли Windows Server и мощные сервера. Ну и заодно CAL лицензии и SQL Server.
И с чем мы остались? А ни с чем. Поэтому решили плясать от наших потребностей.

Железо.

Нам нужна система с большим количеством не очень навороченных серверов с 20-22 ядрами на борту. Из расчета – 1 сервер на 10 виртуалок. С минимум дискового пространства. Все файлы пользователей хранятся на файловом сервере.
20 серверов по 1U – это дофига места в стойке. Значит, простые сервера нам не походят.
А давайте посмотрим в сторону блейд серверов. SuperMicro: MicroBlade или SuperBlade.
Выбрали двух процессорное лезвие, корзину со встроенным коммутатором и получили вот такую табличку (напоминаю, цены на конец 2017 года).


Лезвий:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Вм на лезвие:
10
Micro Blade
Итого:
429 556
630 556
831 556
1 032 556
1 233 556
1 434 556
1 635 556
1 836 556
2 037 556
2 238 556
2 439 556
2 640 556
2 841 556
3 042 556
шасси
228 556
Кол-во вм.:
10
20
30
40
50
60
70
80
90
100
110
120
130
140
лезвие
201 000
За вм.:
42 956
31 528
27 719
25 814
24 671
23 909
23 365
22 957
22 640
22 386
22 178
22 005
21 858
21 733
Вм на лезвие:
10
Super Blade
Итого:
450 896
665 178
879 460
1 093 742
1 308 024
1 522 306
1 736 588
1 950 870
2 165 152
2 379 434
2 593 716
2 807 998
3 022 280
3 236 562
шасси
236 614
Кол-во вм.:
10
20
30
40
50
60
70
80
90
100
110
120
130
140
лазвие
214 282
За вм.:
45 090
33 259
29 315
27 344
26 160
25 372
24 808
24 386
24 057
23 794
23 579
23 400
23 248
23 118



Итого: первоначальное вложение на железо на 10 рабочих мест: 429 556 рублей.
Дельта вложений для увеличения количества рабочих мест: 201 000 рублей.
Максимальная ёмкость 140 рабочих мест (на самом деле больше, одно лезвие может тянуть 12-14 виртуалок), итоговая цена вопроса: 3 042 556 рублей.

Цена рабочего места при полной комплектации: 21 733 рублей.

О! Это уже гуд. Эти цифры можно показывать руководству.

Софт.

Напоминаю, нам надо:
  •         По возможности быстро развернуть новое рабочее место.
  •         Снапшоты.
  •         Бекапы рабочих мест.
  •         Удобство для админов.
  •         Вируализировать простые рабочие станции обычных пользователей, без тяжелого софта.

Без всего остального можно обойтись.
Учитываю околонулевые знания Linux нашими админами, родные линуксовые системы виртуализации не подходят. Что же делать? Учить их Linux или рассмотреть что то ещё?
И тут я вспомнил про VirtualBox. Эй, не надо кидаться тухлыми яйцами. Вас бы поставить в наши условия вы бы со страху написали свой гипервизор :).
Ну а если серьезно у VirtualBox есть очень много преимуществ, учитывая наши конкретные запросы.
Во первых, бокс реализует все наши запросы кроме удобства для админов. Все равно надо по sshзаходить на сервер и в командной строке создавать машины, работать со снапшотами и делать прочие административные действия. Но это можно обойти. Как? Напишу ниже.
Во вторых, и это одно из ключевых его преимуществ! Бокс избавляет нас от покупки CAL лицензий для подключения по RDP к гостевой машине! Да, Вы будете подключаться к гостевой машине по RDP, но Вы будете подключаться не к RDP сервису, работающему в Windows, а к RDP сервису, работающему в VirtualBox. А для этого лицензии не надо.
В третьих, в виртуалке можно крутить любые версии Windows. Хоть Windows 10 Home, у Вас все равно будет к ней доступ по RDP.
В четвёртых, к этому сеансу могут одновременно подключаться и пользователь и админ. Причем они получают доступ с самого старта системы. Это позволяет сэкономить на софте типа radmin и его производных.
Ну и еще несколько приятных вещей.

Удобство администрирования.

Разумеется, данное решение не предоставляет всех удобств вмваре и другого коммерческого софта. Но имея в компании программиста (разумеется не 1С :)), Вы можете за 3 недели написать свой софт для управления фермой ВиртуалБоксов.

Во всяком случае лично мне понадобилось три недели, что бы разобраться с предоставляемым VirtualBox-м java API, что бы разобраться с JavaFX и написать софт, облегчающий работу линейным админам. Вот такой:

Всё пропало шеф.

Ну и печалька. После всех приготовлений, тестов, по не зависящим от нас обстоятельствам, внедрение системы отложили.
Вот так мы сэкономили компании 15 лямов, ничего не внедрив. А вы так можете? 🙂

Управление питанием web камеры при помощи mikrotik

Артур Крюков

На одном нашем объекте барахлят web камеры. Очень чувствительные к питанию. Постоянно приходиться их вкл/выкл. Каждый вкл/выкл стоит 1000 р. в обслуживающей организации (объект в другом городе). Да и время уходит, пока парни из саппорта приедут и дернут шнурок питания, строители могут пару самосвалов налево вывезти :).

Камеры без поддержки POE, но питание передаётся по ethernet кабелю. Стоит блок питания необходимой мощности, POE инжектор. На стороне камеры девайс, который из кабеля берет питание и дает его на камеру.

Изначально хотели брать питание с микротика, который там стоит, но когда нам согласовали камеры, выяснилось, что мощи микротика для них не хватает. Поэтому получилась вот такая хитрая фигня.

По идее нужно вставить девайс, который по сигналу отрубает питание камеры и врубает его обратно. Реле, управляемые по Ethernet, стоят куеву тучу денег. Естественно мы их не купили.

Начали гуглить проблему и нашли записки доброго человека из lanmart: https://www.lanmart.ru/blogs/mikrotik-rb750up-remote-power-management-220v/

Он при помощи микротика с POE out управляет автомобильным реле, которое разрывает цепь 220 вольт. Вобщем наша тема!

Мы сделали точно так, но разрывали слаботочку 12 вольт. Реле поместили в корпус блока питания. Ethernet кабель маленько разрезали по середине. Все надрезы основательно изолировали. И вот итог:

На картинке второй конец кабеля воткнут в Mikrotik cAP. Свободный засовывали в управляющий микротик с POE out.

Автомобильное реле влезло в корпус блока питания. Но вот развести провода Ethernet места уже не хватило. Пришлось делать сопливую врезку:

Чуть крупнее.

Бомж комплект собран и работает.

Завтра соберем еще два таких «девайса» и поедем на объект ставить.