Русский
Русский
English
Статистика
Реклама

It-инфраструктура

Сверхточный Raspberry PI Stratum 1 NTP сервер

07.07.2020 12:09:02 | Автор: admin
В этой статье я расскажу, как собрать Stratum 1 NTP сервер на Raspberry PI для синхронизации времени за скромную сумму и навсегда забыть о проблемах, связанных с не совпадающим временем на всех ваших устройствах. А самое главное, он будет давать результат на два порядка точнее, чем обычный сервер.

В предыдущей статье, посвященной синхронизации времени по радио и СРНС (системы радионавигационной связи), я не успел рассказать про выбор приёмника GPS / ГЛОНАСС с выходом PPS. Между тем от этого зависит точность приёма сигнала, величина может составить от одной миллисекунды до нескольких микросекунд и зачастую это имеет решающее значение.

Для самого точного приема сигнала времени нужен приёмник GPS / ГЛОНАСС с выходом PPS. Дело однако в том, что на российском рынке не просто раздобыть устройство с такими характеристиками по доступной цене. Много таких моделей давно уже перестали выпускать, а в заброшенных интернет магазинах с версткой 1990-х остались лишь их описания с предложением подписаться на уведомление при поступлении товара.


Полный список протестированного GPS оборудования можно найти на GitLab ресурсе NTPSec. Не трудно заметить, что незначительное число представленных в списке устройств имеют отметку 3-4 звезды и опцию PPS. Таким образом, в шорт-лист попадают следующие приёмники.

  • Garmin GPS-18, не USB *** (приблизительная цена 10 тыс. р.)
  • GlobalSat MR-350P ****
  • Jackson Labs FireFly-II ***
  • Magellan Thales AC12 ***
  • Motorola Oncore GT+ ***
  • Navisys GR601-W ****
  • SkyTraq SKG16B ****
  • Trimble Lassen IQ ***
  • u-blox ANTARIS LEA-4T ***
  • u-blox EVK 6H ****
  • u-blox LEA SQ ****

4* Отличная производительность: gpsd распознает приёмник быстро и надежно, а отчеты сформировано полностью и правильно.

3* Хорошая производительность: gpsd с незначительными проблемами или задержкой распознаёт устройства, но отчеты сформировано полностью и правильно.

Если вас не пугает цена этих моделей, а также нет большого желания возиться с железками, можете не читать дальше. Приемник, подключенный к серверу по USB, или RS232 интерфейсу обеспечит гораздо большую точность определения времени, чем NTP сервер, работающий по tcp/ip. Но если путь самурая вам не чужд, тогда давайте собирать свой Raspberry PI NTP сервер с GPS синхронизацией времени.

Собираем Raspberry PI


Итак: берем следующие компоненты для нашего микро сервера.

  1. Плата Raspberry Pi 4 Model B, 4 GiB ОЗУ (6200 руб.);
  2. Корпус, например такой (890 руб.);
  3. Micro SD карта на 32 GiB, можно и 16 GiB; (540 руб.)
  4. GPS модуль на чипе u-blox NEO-M8 (1700 руб. с антенной);
  5. GPS антенна на 15 dB;
  6. Паяльник.

Вообще-то, u-blox NEO-M8 оснащен UART интерфейсом, но для PPS выхода необходимо припаять pin-3 на GPS модуле к соответствующему GPIO коннектору на плате Raspberri Pi. Модуль швейцарской компании завоевал популярность у специалистов и это не случайно, характеристики говорят сами за себя.

  • Поддерживаемые СРНС: BeiDou, Galileo, GNSS; GPS/QZSS, GLONASS;
  • Напряжение питания: 2.7...3.6 В;
  • Интерфейсы: UART, USB, SPI, DDC, I2C;
  • Поддерживаемые протоколы: NMEA 0.183 version 4.0, UBX (binary), RTCM 2.3;
  • Чувствительность при обнаружении: -167 дБм;
  • Чувствительность при слежении: -160 дБм;
  • Время холодного старта: 26 с;
  • Время горячего старта: 1.5 с;
  • Потребляемая мощность: 35 мВт;
  • Рабочая температура: -40...+85 С;
  • Размеры: 16х12.2х2.4 мм

В такой конфигурации с новейшим оборудованием примерная общая цена Raspberry PI в собранном виде составит 9330 руб. Можно сэкономить, купив Raspberry PI 3, или четверку с 2 GiB ОЗУ. Можно еще сэкономить на GPS чипе, u-blox NEO-6M с антенной стоит около 650 руб. Тогда цена NTP сервера упадет до 5500 руб.


GPS/Глонасс модуль UBLOX NEO 8M

Может возникнуть вопрос, для чего нужны все эти капиталовложения и какую точность обеспечивает тот, или иной способ синхронизации времени. Небольшая сводная табличка для справки.
Источник сигнала времени Погрешность
GPS с атомными часами 50 nSec
KPPS 1 Sec
PPS 5 Sec
Интерфейс USB 1.1 1 mSec
Интерфейс USB 2.0 100 Sec (100000 nSec)
NTP по сети ~30 mSec

Kernel PPS (KPPS) отличается от PPS тем, что использует функцию ядра Linux / Unix для точной временной отметки изменения состояния в строке PPS. Обычный же PPS реализован в user-space. Если ядро Linux поддерживает KPPS через API RFC 2783, gpsd воспользуется им для увеличения точности.

Во многих дистрибутивах Linux имеется пакет pps-tools, который обеспечивает поддержку KPPS и устанавливает timepps.h заголовочный файл. Обязательно установите этот пакет.

(1:1146)$ sudo emerge -av pps-toolsLocal copy of remote index is up-to-date and will be used.These are the packages that would be merged, in order:Calculating dependencies... done![binary   R    ] net-misc/pps-tools-0.0.20120407::gentoo  0 KiBTotal: 1 package (1 reinstall, 1 binary), Size of downloads: 0 KiBWould you like to merge these packages? [Yes/No] 

Таким образом, подключив GPS приёмник с PPS выходом по USB мы получаем 300-кратное повышение точности синхронизации времени. Чтение с чипа GPS на плате в режиме KPPS даёт прирост точности еще на два порядка.

Будем откровенны не все из нас умеют пользоваться паяльником, далеко не каждый пользуется этим инструментом регулярно. В таком случае имеет смысл поискать модуль GPS, не требующий пайки контактов.


Raspberry Pi GPS/RTC Expansion Board

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

Установка ОС


Существует Raspberry PI OS, а. k. a. Raspbian, можно просто пойти по ссылке, скачать свежую версию и установить её. Многие так и делают, но давайте вспомним, что Raspberry PI 4 поддерживает 64-битную операционную систему, в то время как Raspberry PI OS пока имеет лишь 32-битные модификации Debian Linux для архитектуры Arm.

Существует такая точка зрения, что на 64-битная ОС неоправдана на Raspberry PI 4, так как нет возможности обеспечить прирост производительности из-за особенностей архитектуры и сборки. Мне эта точка зрения представляется сомнительной, об этом уже писали на Хабре 64-битная ОС быстрее.

Существует порт Debian Linux для архитектуры arm64, однако дистрибутив Убунту для Raspberry PI имеет внятную страницу и инструкцию. На странице находим дополнительное подтверждение тому, что лучше выбрать 64-битную ОС.



Инвентарь для установки:

  • Raspberry Pi 4;
  • USB-C кабель питания для Pi 4;
  • Micro SD карта с установочным образом Убунту;
  • Монитор с выходом HDMI;
  • Кабель MicroHDMI;
  • USB клавиатура.

Следующий этап запись установочного образа на Micro SD карту. Если у вас под рукой нет специализированной утилиты и программы под эти цели, в простейшем случае достаточно.

sudo dd if=/path/to/ubuntu-core-arm64.iso of=/dev/mmcblk0 status=progress

Точное название устройства видно в выводе dmesg при обнаружении нового устройства.

PM: Adding info for No Bus:179:0device: 'mmcblk0': device_addPM: Adding info for No Bus:mmcblk0

Вставив Micro SD карту, подключив HDMI-монитор, USB-клавиатуру, и кабель питания загружаетесь в Ubuntu Server на Raspberry Pi. Имя пользователя и пароль по умолчанию ubuntu.

Настройка NTP сервера


  1. Если Raspberry PI включен в консольном режиме (headless), то для начала необходимо определить IP адрес устройства. С рабочей станции наберите следующую команду.

    (1:1151)$ arp -na | grep -i "dc:a6:32"
    

    Ели же Pi подключен к HDMI монитору и USB клавиатуре, пропустите шаги 1-2 и переходите сразу к установке пакетов.
  2. Подключитесь по ssh

    (1:1152)$ ssh ubuntu@<Raspberry Pis IP address>
    
  3. Установите необходимые пакеты.

    user@server ~$ sudo apt-get install aptitudeuser@server ~$ sudo aptitude install wpasupplicant gpsd chrony
    
  4. Настройте Wi-Fi соединение с помощью wpasupplicant.
  5. В Linux UART0 интерфейс Pi представлен файлом устройства /dev/ttyAMA0. Для того чтобы освободить UART0 интерфейс для GPS приёмника нужно поменять параметры загрузки ядра Linux. Необходимо отключить console=ttyAMA0,115200, заменив на console=tty1. Для этого в файле /etc/default/grub надо поменять GRUB_CMDLINE_LINUX_DEFAULT. Если существует файл, /boot/config.txt, в нем также можно задать те же опции.

    Raspberry Pi 4 имеет 6 UART-ов
    Название Тип Устройство Назначение
    UART0 PLO11 /dev/ttyAMA0 вторичный (Bluetooth)
    UART1 mini UART /dev/ttyS0 основной
    UART2 PLO11
    UART3 PLO11
    UART4 PLO11
    UART4 PLO11
    По умолчанию UART2-5 выключены.

    Как видно из названия, UART0 полноценный серийный порт и он имеет более высокую производительность, чем обрезанный UART1, он же mini UART. Поэтому будет не лишним перевести Bluetooth на UART1 с тем, чтобы основной поток данных шел через UART0. Для этого в /etc/default/grub, или /boot/config.txt ставим enable_uart=1.
  6. В файле /etc/defaults/gpsd следует выставить.

    DEVICES="/dev/ttyAMA0 /dev/pps0"GPSD_OPTIONS="-n"USBAUTO="false"
    
  7. Запустите, или перезапустите gpsd.

    user@server ~$ sudo /etc/init.d/gpsd startuser@server ~$ sudo /etc/init.d/gpsd restart
    
  8. Проверка работы модуля GPS.

    user@server ~$ cat /dev/ttyAMA0user@server ~$ cgps -suser@server ~$ ppstest /dev/pps0
    
  9. Отредактируем файл /etc/ntp.conf.

    Все строки, содержащие сетевые публичные Stratum 1, 2 NTP сервера (такие, как pool [0-9].subdomain.pool.ntp.org) следует закомментировать, чтобы использовать лишь GPS/PPS источники данных.

    # GPS Serial data reference (NTP0)server 127.127.28.0 minpoll 4fudge 127.127.28.0 flag1 1 time1 0.9999 refid GPS #flag1 - PPS on
    

    # GPS PPS reference (NTP1)server 127.127.22.0 minpoll 4fudge 127.127.22.0 flag3 1 refid PPS #flag3 - enable KPPS API
    

    Верхняя запись NTP0 указывает на универсальный источник времени, доступный почти на всех устройствах GPS. Нижняя запись NTP1 определяет гораздо более точный PPS источник.
  10. Перезапустите ntpd

    user@server ~$ sudo /etc/init.d/ntpd restart
    

Использованные материалы



Подробнее..

Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V

29.06.2020 10:05:23 | Автор: admin

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.



В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:


  1. Физическая и логическая коммутация
  2. Действия на стороне СХД
  3. Действия на стороне хоста(ов)

В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.


Физическая и логическая коммутация


Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.



В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).



Важные замечания по поводу параметров SAN сети:
  • Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;
  • Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;
  • Для протокола Fibre Channel необходимо настроить в коммутаторах зонирование по принципу один инициатор один или несколько таргетов для исключения влияния серверов друг на друга;
  • Для iSCSI соединений со скоростью 10G и выше рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, физические и виртуальные порты сетевых карт серверов.


Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports



В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections Свойства конкретного адаптера Configure Advanced Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)



Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.


Действия на стороне СХД


Необходимые настройки на СХД можно разделить на два этапа:


  • Настройка интерфейсов
  • Настройка пространства хранения

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.



В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.


Далее необходимо создать пространство хранения. Сначала создается пул группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools Create Pool, где запускается пошаговый мастер.


  • Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными.
  • Выбрать конкретные диски
  • Уровень RAID
  • Указать параметры физических накопителей, влияющие на их производительность.
    Рекомендуется использовать установки по умолчанию для максимальной скорости:
    • Enable Disk Write Cache
    • Enable Disk Read-ahead
    • Enable Disk Command Queuing
    • Disable Disk Standby





Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.


После создания пула(ов) необходимо создать тома (volume): Volumes Create volumes. Также запустится пошаговый мастер создания тома.




Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.


  • Block Size размер блока, который будет эмулироваться для хоста. Для Windows Server рекомендуется задать значение 4КБ как наиболее оптимальное.
  • Background I/O Priority приоритет фоновых задач (расширение, миграция и пр.)
  • Erase Volume Data необходимость зануления создаваемого тома. Значение Fast Erase соответствует записи нулей в первый гигабайт пространства, может быть полезно при повторном использовании дисков с целью удалить остатки предыдущих данных (стереть таблицы размещения). Full Erase запись нулей по всему объему, полезно для достижения максимальной производительности в случае использования RAID 1/10.
  • Enable Cache Mode (Write-back Cache) включение кэша СХД. Очень сильно влияет на производительность.
  • Enable Video Editing Mode снижение производительности ради более стабильных результатов. Если не предполагается использование тома в системах видеонаблюдения, лучше выключить данный параметр.
  • Enable Read-ahead включение упреждающего чтения. Положительно влияет на производительность.
  • Enable Fast RAID Rebuild при активации данной настройки система будет вести трекинг всех записываемых блоков, чтобы понимать, сколько реальных данных записано на том. В случае выхода из строя диска в составе RAID группы во время ребилда не будут копироваться пустые блоки, что может ускорить данный процесс. Однако стоит помнить, что использование Fast Rebuild снижает производительность при случайном доступе.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping Map LUN.




  • Необходимо выбрать протокол доступа: FCP (Fibre Channel) или iSCSI. Доступ к одному и тому же тому может быть только через один протокол.
  • Allowed Host список хостов, которым разрешен доступ к тому. По умолчанию разрешено всем (*). Однако рекомендуется всегда явно указывать разрешения для исключения конфликтов доступа и, соответственно, повреждения файловой системы. Для Fibre Channel указываются WWPN хостов (с возможностью выбора из всех доступных в SAN сети). Для iSCSI указываются IQN хостов. В случае нескольких хостов они добавляются по кнопке Add Host. Со стороны Windows значения WWPN и IQN можно узнать через консольную (PowerShell) команду Get-InitiatorPort


  • LUN ID с которым том будет виден хостам. Также по этому идентификатору легко опознать том со стороны сервера. В случае использования Windows Cluster для корректной работы LUN ID должен быть одинаковым для одного и того же тома для всех узлов кластера.

Действия на стороне хоста


Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features



При использовании протокола iSCSI необходимо выполнить:


  • В свойствах Software iSCSI Initiator необходимо указать адреса таргетов, т.е. СХД на вкладке Discovery должны быть введены все используемые IP адреса контроллеров СХД
  • После обнаружение таргетов к ним необходимо подключиться при помощи кнопки Connect. Отметим важные детали:
    • Необходимо добавить подключаемые таргеты в список Избранных, чтобы в случае разрыва соединения происходило автоматическое переподключение
    • Необходимо включить поддержку MPIO
    • Хотя автоматическое определение маршрутизации в большинстве случаев работает корректно, мы все же рекомендуем не пренебрегать явным указанием с какого сетевого интерфейса сервера необходимо подключаться к конкретному таргету (Advanced Settings)
    • Если через один и тот же сетевой интерфейс сервера производится работа с нескольким портами СХД, то подключение через Connect нужно проделать для каждого пути


  • После любого изменения параметров СХД и SAN сети необходимо выполнить Rescan в стандартной оснастке управления дисками или в Device Manager. Итогом будет появление (т.к. мы добавляем новый том) нового устройства, доступного в нашем конкретном примере по 4 путям (согласно топологии подключения через два коммутатора в Discovery указано 4 IP адреса портов СХД) с LUN ID = 0, как мы и задавали при публикации на СХД. Также следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.


При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN ID = 1, доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.



Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству это отдельный диск.



Чтобы ОС склеила все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.



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


В рамках этой статьи были рассмотрены преимущественно базовые операции, необходимые для подключения серверов Windows Server к СХД Qsan. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.
Подробнее..

Отказоустойчивость между 5 дата-центрами как мы разгребаем зоопарк

30.06.2020 10:05:46 | Автор: admin
Сейчас мы стоим в 4 физически разных ЦОДах, соединённых кольцом тёмной оптики, размещая там 5 независимых пула ресурсов. И так получилось, что если в одну из кроссовых попадёт метеорит, то у нас тут же отвалится 3 этих пула, а оставшиеся два не потянут нагрузку. Поэтому мы занялись полной ребалансировкой, чтобы навести порядок. Вообще, оглядываясь назад, могу сказать, что все действия по размещению это вынужденные ходы. И вот только сейчас на 15-й год мы можем настраивать инфраструктуру так, как нужно нам.



По дороге нам пришлось научиться готовить ProxySql балансировщики MySQL и немного закопаться в сетевой стек. Но, пожалуй, начну с самого начала. А начиналось всё с shared hosting и VPS в Мастехосте, на которых крутилось наше расписание электричек, которое многие из вас видели. И эти сервера получали тройной трафик на майские, отчего сразу ложились. Точнее, мы не знаем, какой трафик они получали, потому что ложились именно на тройном от обычного.


Первый ЦОД


Сначала ЦОДа вообще не было. Был старый системник в общаге МГУ. Потом, почти сразу виртуальный хостинг у Мастерхоста (они ещё живы, чертяки). Посещаемость сайта с расписанием электричек удваивалась каждые 4 недели, поэтому очень скоро мы перешли на KVM-VPS, это случилось примерно в 2005 году. В какой-то момент мы упёрлись в ограничения по трафику, поскольку тогда надо было соблюдать баланс между входящим и исходящим. У нас было две инсталляции, и мы перекладывали с одной на другую пару увесистых файлов каждую ночь, чтобы соблюсти требуемые пропорции.

В марте 2009 были только VPS. Это дело хорошее, решили переходить на colocation. Купили пару физических железных серверов (один из них тот самый со стены, тело которого мы храним как память). Поставили в ЦОД Фиорд (и они ещё живы, чертяки). Почему? Потому что было недалеко от тогдашнего офиса, порекомендовал знакомый, и вставать надо было быстро. Плюс было сравнительно недорого.

Разделение нагрузки между серверами было простым: на каждом был бэк, MySQL с master-slave репликацией, фронт был там же, где и реплика. Ну т.е. почти без разделения по типу нагрузки. Довольно скоро их тоже начало не хватать, купили третий.

Примерно 1 октября 2009 мы поняли, что серверов уже больше, но на новый год ляжем. Прогнозы по трафику показывали, что возможная мощность будет перекрыта с запасом. Причём упирались мы в производительность БД. Был месяц полтора на подготовку перед ростом трафика. Это было время первых оптимизаций. Купили пару серверов чисто под БД. Там делали акцент на быстрые диски со скоростью вращения 15krps (не помню точную причину, почему мы не использовали SSD, но скорее всего они имели невысокий лимит по количеству операций записи, и при этом стоили, как самолет). Разделили фронт, бэк, базы, подкрутили настройки nginx, MySQL, провели ресеч по оптимизации SQL запросов. Пережили.

Сейчас-то мы стоим в паре Tier-III ЦОДов и в Tier-II по UI (с замахом на T3, но без сертификатов). А вот Фиорд был ни разу даже не T-II. У них были проблемы по живучести, бывали ситуации из разряда все провода питания в одном коллекторе, а там пожар, а генератор ехал три часа. В общем, решили переезжать.

Выбрали ещё один ЦОД, Караван. Задача: как переехать серверами без даунтайма? Решили пожить на два ЦОДа какое-то время. Благо трафика внутри системы на тот момент было не столько, как сейчас, можно было гонять трафик по VPN между локациями какое-то время (особенно вне сезона). Сделали балансировку трафика. Постепенно увеличивали долю Каравана, через некоторое время полностью переехали туда. И вот у нас остался один ЦОД. А нужно два, мы это уже понимали, спасибо сбоям у Фиорда. Оглядываясь на те времена, могу сказать, что TIER III тоже не панацея, живучесть-то будет 99.95, но вот доступность это другое. Так что одного ЦОДа для доступности 99.95 и выше точно не хватит.

Вторым выбрали Стордату, и там уже была возможность оптического линка с площадкой Каравана. Успели протянуть первую жилу. Только начали загружать новый ЦОД, как Караван объявил, что у них наступила задница. Им надо было покинуть площадку, потому что здание сносят. Уже. Сюрприз! Новая площадка есть, предлагают потушить все, кранами поднять стойки с оборудованием (тогда у нас уже было 2.5 стойки железа), перевести, включить, и все заработает 4 часа на все сказки я уж молчу, что нам даже час простоя не подходил, а тут история на сутки минимум затянулась бы. Причём подавалось всё это в духе Всё пропало, гипс снимают, клиент уезжает!. 29 сентября первый звонок, а числа 10-го октября они хотели забрать всё и везти. За 3-5 дней нам пришлось разработать план переезда, и в 3 этапа, выключая по 1/3 оборудования за раз с полным сохранением сервиса и аптайма перевезти машины в Стордату. В итоге простой был 15 минут в одном не самом критичном сервисе.

Так мы опять остались с одним ЦОДом.

В этот момент нам надоело таскаться с серверами под мышкой и играть в грузчиков. Плюс надоело заниматься самим железом в ЦОДе. Стали смотреть в сторону публичных облаков.

От 2 до 5 (почти) ЦОДов


Начали искать варианты с облаками. Вышли на Крок, попробовали, протестировали, договорились по условиям. Мы встали в облако, которое в ЦОДе Компрессор. Сделали кольцо тёмной оптики между Стордатой, Компрессором и офисом. Везде свой аплинк и два плеча оптики. Перерубание любого из лучей не рушит сеть. Потеря аплинка не рушит сеть. Получили статус LIR, есть своя подсеть, BGP анонсы, сеть резервируем, красота. Как именно заходили в облако с точки зрения сети здесь описывать не буду, но были нюансы.

Так у нас стало 2 ЦОДа.

У Крока есть еще ЦОД на Волочаевской, они расширили свое облако и туда, предлагали перенести часть ресурсов наших туда. Но помня историю с Караваном, который, по сути, так и не оправился после сноса ЦОДа, захотелось облачные ресурсы брать у разных провайдеров, чтобы уменьшить риск, что компания перестанет существовать (страна такая, что игнорировать такой риск нельзя). Поэтому с Волочаевской не стали связываться на тот момент. Ну и ещё второй вендор делает магию с ценами. Потому что, когда вы можете взять и эластично уехать, это даёт сильную переговорную позицию по ценам.

Смотрели разные варианты, но выбор пал на МТС.Cloud. Тому было несколько причин: облако на тестах показало себя хорошо, с сетью ребята тоже умеют работать (телеком оператор все-таки), и очень агрессивная маркетинговая политика захвата рынка, как следствие, интересные цены.

Итого 3 ЦОДа.

Дальше все-таки мы подключили и Волочаевскую нужны были дополнительные ресурсы, а в Компрессоре уже было тесновато. В общем, перераспределили нагрузку между тремя облаками и своим оборудованием в Стордате.

4 ЦОДа. Причём уже по живучести везде T3. Сертификаты, кажется, не у всех есть, но не буду утверждать точно.

У МТС был нюанс. Ничего кроме МГТС последней милей туда зайти не могло. При этом тянуть темную оптику МГТС целиком от ЦОДа до ЦОДа не было возможности (долго, дорого, и, если я не путаю, они такую услугу и не предоставляют). Пришлось делать со стыком, выводить два луча из ЦОДа до ближайших колодцев, где есть наш провайдер темной оптики Мастертел. У них разветвлённая сеть оптики по всему городу, и, если что, они просто сваривают нужный маршрут и дают вам жилу. А в это время Чемпионат мира по футболу пришел в город, неожиданно, как снег зимой, и доступы в колодцы в Москве закрыли. Мы ждали, пока это чудо закончится, и мы сможем прокинуть свой линк. Казалось бы, нужно было выйти из ЦОДа МТС с оптикой в руках, посвистывая дойти до нужного люка и опустить её туда. Условно. Делали три с половиной месяца. Точнее первый луч сделали довольно быстро, к началу августа (напомню, что ЧМ закончился 15 июля). А вот со вторым плечом пришлось повозиться первый вариант подразумевал, что надо перекопать Каширское шоссе, для чего перекрыть его на недельку (там при реконструкции завалило какой-то туннель, где лежат коммуникации, надо откапывать). К счастью, нашли альтернативу: другой маршрут, такой же геонезависимый. Получилось две жилы от этого дата-центра до разных точек нашего присутствия. Кольцо оптики превратилось в кольцо с ручкой.

Чуть забегая вперёд, скажу, что всё равно нам его положили. К счастью, в самом начале эксплуатации, когда еще мало всего перенесли. В одном колодце случился пожар, и пока монтажники матерились в пене, во втором колодце кто-то вытащил посмотреть коннектор (какой-то он был новой конструкции, интересно же). Математически вероятность одновременного сбоя была ничтожна. Практически мы его поймали. Собственно, нам и во Фиорде везло там рубанулось основное питание, и вместо включения его обратно, кто-то перепутал рубильник и выключил резервную линию.

Были не только технические требования по распределению нагрузки между локациями: чудес не бывает, и агрессивная маркетинговая политика с хорошими ценами подразумевает определенные темпы роста потребления ресурсов. Так что мы все время держали в голове, какой процент ресурсов надо отправить в МТС обязательно. Всё остальное мы перераспределяли между другими ЦОДами более-менее равномерно.

Снова своё железо


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

Искали решение, которое бы позволило получить облако на своем железе относительно легко. На тот момент мы никогда не работали с серверами Cisco, только с сетевым стеком, в этом был риск. На Деллах же простое хорошо знакомое железо, надёжное как автомат Калашникова. У нас такое стояло годами, и до сих пор где-то есть. Но идея Hyperflex в том, что он из коробки поддерживает гиперконвергентность итогового решения. А у Делла всё живёт на обычных маршрутизаторах, и там есть нюансы. В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда. В смысле, их можно правильно настроить и будет супер, но мы решили, что это не наш бизнес, и пусть Делл готовят те, кто находит в этом призвание. В итоге выбрали Cisco Hyperflex. Этот вариант победил по совокупности как самый интересный: меньше геморроя в настройке и эксплуатации, и во время тестов все было хорошо. Летом 2019 запустили кластер в бой. У нас была полупустая Стойка в Компрессоре, занятая по большей части только сетевым оборудованием, там и разместили. Таким образом получили пятый ЦОД физически-то четыре, но по пулам ресурсов получилось пять.

Взяли, посчитали объём постоянной нагрузки и объём переменной. Постоянную превратили в нагрузку на своё железо. Но так, чтобы на уровне оборудования давало облачные преимущества по отказоустойчивости и резервированию.

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

Вы находитесь здесь


В этот момент у нас закончились вынужденные ходы. Как видите, у нас не было особо вариантов экономически, и постоянно мы нагружали то, куда должны были встать по каким-то причинам. Это привело к странной ситуации, что нагрузка неравномерная. Отказ любого сегмента (а сегмент с ЦОДами Крока держится на двух Нексусах в узком месте) это потеря пользовательского опыта. То есть сайт сохранится, но будут явные сложности с доступностью.

Был сбой в МТС со всем ЦОДом. Было ещё два в других. Периодически отваливались облака, либо контроллеры облаков, либо возникала какая-то сложная сетевая проблема. Короче, мы время от времени теряем ЦОДы. Да, кратковременно, но все равно неприятно. В какой-то момент приняли за данность, что ЦОДы отваливаются.

Решили идти на отказоустойчивость уровня дата-центров.

Сейчас мы не ляжем, если откажет один из 5 ЦОДов. Но вот если потеряем плечо Крока будут очень серьёзные просадки. Так и родился проект отказоустойчивости дата-центров. Цель такая если ДЦ умрёт, сеть до него умрёт или оборудование умрёт, сайт должен работать без вмешательства руками. Плюс после аварии мы должны штатно восстановиться.

В чём подводные камни



Сейчас:


Нужно:


Сейчас:


Нужно:


Эластик устойчив к потере одной ноды:


MySQL базы (много небольших) управляются достаточно сложно:




Про это лучше детальнее напишет мой коллега, который делал балансировку. Важно то, что до того, как мы навесили это, если мы теряли мастера, то надо было руками зайти на резерв и там поставить флажок r/o=0, перестроить на этот новый мастер ансиблом все реплики, а их в основной гирлянде более двух десятков, поменять конфиги приложения, потом раскатать конфиги и дождаться обновления. Сейчас приложение ходит по одному anycast-ip, который смотрит на LVS балансировщике. Постоянный конфиг не меняется. Вся топология баз на оркестраторе.

Сейчас между нашими ЦОДами протянута тёмная оптика, которая позволяет обращаться к любому ресурсу в пределах нашего кольца как к локальному. Время ответа между ЦОДами и время внутри плюс-минус одинаковое. Это важное отличие от других компаний, которые строят геокластеры. Мы очень сильно завязаны на своё железо и свою сеть, и мы не пытаемся локализовать запросы внутри ЦОДа. Это с одной стороны круто, а с другой если захотим в Европу или в Китай, то свою тёмную оптику не вытащим.

Это означает ребалансировку почти всего, в первую очередь баз данных. Много схем, когда активный мастер и на чтение, и на запись держит всю нагрузку, а рядом реплика синхронная для быстрого переключения (мы не пишем в два сразу, а именно реплицируем, иначе работает не очень хорошо). Основная база при этом в одном ЦОДе, а реплика в другом. Ещё частичные копии могут быть в третьем для отдельных приложений. Таких инстансов от 10 до 15 в зависимости от времени года. Оркестратор растянутый кластер между цодами 3 ЦОДами. Тут мы детальнее расскажем ещё, когда найдутся силы описать, как вся эта музыка играет.

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

В общем, есть ещё чем заняться, но план понятный.
Подробнее..

Перевод Как использовать grok exporter для создания метрик prometheus из неструктурированных журналов

30.06.2020 10:05:46 | Автор: admin

Здесь будет перевод 2 постов про grok exporter.


Первый перевод: Как использовать grok exporter для создания метрик prometheus из неструктурированных журналов


Поговорим о grok exporter. В этой статье я объясню, как можно использовать grok exporter для создания метрик prometheus из неструктурированных журналов.



Grok популярен для обработки журналов в массовом ELK стеке (ElasticSearch, Logstash, Kibana) и благодаря Fabian Stber для разработки grok exporter.


Вот официальная документация grok exporter => https://github.com/fstab/grok_exporter


Шаг 1: Установите Grok exporter


Давайте получим готовый zip файл grok exporter от https://github.com/fstab/grok_exporter/releases.


  1. Перейдите в раздел релизы (releases) и нажмите на последнюю версию (теперь это v0.2.7).
  2. Затем загрузите zip-файл, соответствующий вашей операционной системе. Моя операционная система это 64-битный Linux. Такова будет команда.

wget https://github.com/fstab/grok_exporter/releases/download/v0.2.7/grok_exporter-0.2.7.linux-amd64.zip

  1. Распакуйте файл и перейдите в извлеченный каталог.
  2. Затем выполните команду ниже, чтобы запустить grok exporter.

[root@localhost grok_exporter-0.2.7.linux-amd64]# ./grok_exporter -config ./config.ymlStarting server on http://localhost.localdomain:9144/metrics

Теперь вы можете посмотреть примеры метрик по адресу http://localhost.localdomain:9144/metrics.


Шаг 2: Давайте обработаем некоторые пользовательские журналы


Давайте исследуем некоторые примеры журналов с Grok exporter. Вот несколько случайных журналов, сделанных мной.


30.07.2016 04:33:03 10.3.4.1 user=Nijil message="logged in"30.07.2016 06:47:03 10.3.4.2 user=Alex message="logged failed"30.07.2016 06:55:03 10.3.4.2 user=Alex message="logged in"30.07.2016 07:03:03 10.3.4.3 user=Alan message="logged in"30.07.2016 07:37:03 10.3.4.1 user=Nijil message="logged out"30.07.2016 08:47:03 10.3.4.2 user=Alex message="logged out"30.07.2016 14:34:03 10.3.4.3 user=Alan message="logged out"

Как вы уже могли догадаться, журнал показывает активность входа пользователя в поле. Теперь мне нужно создать метрику Prometheus из этого.


На Шаге 1 вы, возможно, заметили путь config.xml, который упоминается в стартовой команде grok exporter. Откройте конфигурационный файл и замените содержимое нижеприведенными данными.


global:    config_version: 2input:    type: file    path: ./example/nijil.log  # Specify the location of the your log    readall: true              # This should be True if you want to read whole log and False if you want to read only new lines.grok:    patterns_dir: ./patterns    metrics:    - type: counter      name: user_activity      help: Counter metric example with labels.      match: "%{DATE} %{TIME} %{HOSTNAME:instance} user=%{USER:user} message=\"%{GREEDYDATA:data}\""      labels:          user    : '{{.user}}'server:    port: 9144

Схема вышеприведенной конфигурации сделана внизу.


global:    # Config versioninput:    # How to read log lines (file or stdin).grok:    # Available Grok patterns.metrics:    # How to map Grok fields to Prometheus metrics.server:    # How to expose the metrics via HTTP(S).

Шаг 3: Настройка сердца Grok exporter


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


metrics:    - type: counter      name: user_activity      help: Counter metric example with labels.      match: "%{DATE} %{TIME} %{HOSTNAME:instance} user=%{USER:user} message=\"%{GREEDYDATA:data}\""      labels:          user    : '{{.user}}'

Синтаксис шаблона grok это %{SYNTAX:SEMANTIC}, где SYNTAX это имя шаблона, который будет соответствовать журналу, а SEMANTIC это имя поля для присвоения значения сопоставленному журналу. Возьмем в качестве примера %{HOSTNAME:instance}, HOSTNAME это шаблон grok, который только удаляет IP-часть из журнала, и эта IP-часть сохраняется в экземпляре (здесь вы можете дать любое имя), который вы можете использовать позже. Вы должны отметить, что каждый SYNTAX имеет свою собственную цель, это означает, что вы не можете отказаться от IP-адреса в журнале с синтаксисом даты. И как следует из названия, DATE, TIME, HOSTNAME, USER и GREEDYDATA обрывки даты, времени, имени хоста и "любого сообщения" соответственно.


Вы можете использовать метки, чтобы решить, какая метрика на основе параметров должна быть сгенерирована. Из приведенной выше конфигурации вы можете понять, что метрика основана на имени пользователя. Обратите внимание, что вам нужно использовать семантику синтаксиса (SEMANTIC of the SYNTAX) для метки. Для метрики должно быть по крайней мере два параметра. Здесь мы имеем имя пользователя в одной оси и количество вхождений пользователя в другую ось. Второй параметр определяется на основе счетчика метрического типа. Как и Счетчик (Counter), у grok exporter есть и другие метрические типы, узнайте о них из официальных документов.


А теперь займитесь grok exporter ./grok_exporter -config ./config.yml и откройте метрики в браузере. Вы увидите метрики, созданные с именем user_activity, как мы указали в конфигурационном файле.


# TYPE user_activity counteruser_activity{user="Alan"} 2user_activity{user="Alex"} 3user_activity{user="Nijil"} 2

Построение этой метрики в виде графика в Prometheus выходит за рамки данной статьи. Но это очень просто, вам просто нужно указать конечную точку метрики в конфигурации prometheus, чтобы Prometheus мог удалить данные Метрики и построить график для вас.


Второй перевод по теме grok exporter


Второй перевод: Получение метрик из журналов Apache с помощью grok exporter


Не все приложения создают полезные метрики, но некоторые из них создают журналы.


Существует класс приложений, которые практически не имеют полезных метрик, однако информацию, которую вы хотели бы иметь, можно найти в журналах. Одним из вариантов решения этой проблемы является экспортер grok. Допустим, вы работали с Apache, вот несколько примеров журналов из типичного access.log:


x.x.x.x - - [20/Jan/2020:06:25:24 +0000] "GET / HTTP/1.1" 200 62316 "http://178.62.121.216" "Go-http-client/1.1"x.x.x.x - - [20/Jan/2020:06:25:25 +0000] "GET / HTTP/1.1" 200 16061 "-" "Go-http-client/1.1"x.x.x.x - - [20/Jan/2020:06:25:25 +0000] "GET / HTTP/1.1" 200 16064 "-" "Go-http-client/1.1"x.x.x.x - - [20/Jan/2020:06:25:25 +0000] "GET /blog/rss HTTP/1.1" 301 3478 "-" "Tiny Tiny RSS/19.2 (adc2a51) (http://personeltest.ru/away/tt-rss.org/)"x.x.x.x - - [20/Jan/2020:06:25:26 +0000] "GET / HTTP/1.1" 200 16065 "-" "Go-http-client/1.1"x.x.x.x - - [20/Jan/2020:06:25:26 +0000] "GET /blog/feed HTTP/1.1" 200 3413 "-" "Tiny Tiny RSS/19.2 (adc2a51) (http://personeltest.ru/away/tt-rss.org/)"x.x.x.x - - [20/Jan/2020:06:25:27 +0000] "GET /feed HTTP/1.1" 200 6496 "-" "Emacs Elfeed 3.2.0"x.x.x.x - - [20/Jan/2020:06:25:27 +0000] "GET / HTTP/1.1" 200 62316 "http://178.62.121.216" "Go-http-client/1.1"

Для начала загрузите:


wget https://github.com/fstab/grok_exporter/releases/download/v1.0.0.RC2/grok_exporter-1.0.0.RC2.linux-amd64.zip

распакуйте


unzip grok_exporter-*.zipcd grok_exporter*amd64

настройке:


cat << 'EOF' > config.ymlglobal:    config_version: 2input:    type: file    path: access.log    readall: truegrok:    patterns_dir: ./patternsmetrics:    - type: counter      name: apache_http_response_codes_total      help: HTTP requests to Apache      match: '%{COMBINEDAPACHELOG}'      labels:          method: '{{.verb}}'          path: '{{.request}}'          code: '{{.response}}'server:    port: 9144EOF

и запустите grok exporter:


./grok_exporter -config config.yml

Если вы посетите нас http://localhost:9144/metrics вы увидите метрику:


# HELP apache_http_response_codes_total HTTP requests to Apache# TYPE apache_http_response_codes_total counterapache_http_response_codes_total{code="200",method="GET",path="/"} 5apache_http_response_codes_total{code="200",method="GET",path="/blog/feed"} 1apache_http_response_codes_total{code="200",method="GET",path="/feed"} 1apache_http_response_codes_total{code="301",method="GET",path="/blog/rss"} 1

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


Чтобы сделать небольшую резервную копию, Grok это способ, которым вы можете анализировать строки журнала в Logstash (Logstash это L в стеке ELK). Соответственно, паттерны были написаны для многих распространенных приложений, включая Apache. Экспортер Grok позволяет вам строить на существующем корпусе шаблонов, а также добавлять свои собственные, чтобы извлекать метрики из журналов. COMMMONAPACHELOG наверху, например, определяется как


COMMONAPACHELOG %{IPORHOST:clientip} %{HTTPDUSER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)

что само по себе опирается на множество других паттернов. Так что вы должны быть рады, что вам не придется писать это самому с нуля. Поля меток предоставляют вам шаблон Go (как показано в шаблонах Prometheus alerting и notification) для доступа к этим значениям.


Помимо подсчета строк журнала, экспортер Grok может позволить вам наблюдать размеры событий, такие как количество байтов в ответах:


    - type: summary      name: apache_http_response_bytes      help: Size of HTTP responses      match: '%{COMMONAPACHELOG}'      value: '{{.bytes}}'

Или датчики, например, когда был последний запрос:


    - type: gauge       name: apache_http_last_request_seconds      help: Timestamp of the last HTTP request      match: '%{COMMONAPACHELOG}'      value: '{{timestamp "02/Jan/2006:15:04:05 -0700" .timestamp}}'

Это происходит с помощью функции метки времени (timestamp) grok exporter, которая в основном является time.Parse из Golang. Разбор. Есть также функция деления (divide), если вам нужно преобразовать миллисекунды в секунды.


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


Телеграм чат по метрикам https://t.me/metrics_ru

Подробнее..

Подводные камни при переходе на VDI что тестировать заранее, чтобы не было мучительно больно

30.06.2020 10:05:46 | Автор: admin
image

Задумывались когда-нибудь, что делает сканер с VDI-станцией? Сначала всё выглядит хорошо: он пробрасывается как обычное USB-устройство и прозрачно виден с виртуальной машины. Дальше юзер даёт команду на сканирование, и всё к чертям падает. В лучшем случае драйвер сканера, похуже через пару минут софт сканера, потом может поаффектить и других пользователей кластера. Почему? Потому что, чтобы получить пятимегабайтную сжатую картинку, нужно отправить через USB 2.0 на два-три порядка больше данных. Пропускная способность шины 480 Мбит/с.

Так что тестировать надо три вещи: UX, периферию и безопасность обязательно. Есть разница, как тестировать. Можно установить агентов локально, на каждой виртуальной рабочей станции. Это относительно бюджетно, но не показывает нагрузку на канал и не совсем верно считает нагрузку на процессор. Второй вариант развернуться в другом месте нужным количеством роботов-эмуляторов и начать их коннектить к реальным рабочим местам как настоящих пользователей. Добавится нагрузка от протокола передачи видеопотока экрана (точнее, изменённых пикселей), разбор и отправка сетевых пакетов, будут понятны нагрузки на канал. Канал вообще очень редко проверяется.

UX это скорость выполнения разных действий конечным пользователем. Есть пакеты тестов, которые нагружают инсталляцию сотнями пользователей и делают типичные для них действия: запускают офисные пакеты, читают PDF, браузят, редко-редко смотрят порно в рабочее время и так далее.

Довольно хороший пример того, почему такие тесты важны заранее, был в последней инсталляции. Там тысяча пользователей переезжает в VDI, у них офис, браузер и SAP. ИТ-отдел в компании развитый, поэтому есть культура нагрузочного тестирования перед внедрениями. По моему опыту, обычно заказчика приходится уговаривать на такое, потому что затраты большие, а польза не всегда очевидна. Есть же расчёты, где можно ошибиться? На деле такие тесты вскрывают места, где думали, но проверить не могли.

Инсталляция


Шесть серверов, конфигурация вот:

image

К СХД заказчика у нас доступа не было, предоставлялась она уже в виде места как сервис, фактически. Но мы знаем, что там all-flash. Какая именно all-flash, не знаем, но разделы по 10 ТБ. VDI VMware по выбору заказчика, поскольку стек ИТ-команде уже знаком, и всё довольно органично дополняется до целостной инфраструктуры. VMware очень подсаживает на свою экосистему, но если бюджета в закупке хватает годами можно не знать проблем. Но это часто очень большое если. У нас хорошая скидка, и заказчик об этом знает.

Начинаем тесты, потому что ИТ-команда не пускает в прод почти ничего без тестов. VDI это не та вещь, которую можно запустить, а потом принять. Пользователи загружаются постепенно, и с проблемами вполне можно столкнуться через полгода. Чего, естественно, никому не хочется.

450 юзеров в тесте, нагрузку генерируем локально. Робоюзеры делают разные действия одновременно, мы измеряем время каждой операции в течение нескольких часов работы:

image

image

image

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

image

image

image

image

image

image

Собственно, если что-то где-то тормозит нужно менять настройки VDI-фермы, в частности, распределение ресурсов между пользователями разных категорий.

Периферия


С периферией обычно три ситуации:

  • Заказчик просто говорит, что ничего не подключаем (ну, кроме гарнитур, они обычно видны из коробки). Последние примерно лет пять я очень-очень редко вижу гарнитуры, которые не подцепились бы сами по себе, и которые не подхватила бы VMware.
  • Второй подход берём и в рамках проекта внедрения VDI меняем периферию: берём протестированное нами и заказчиком поддерживаемое. Случай по понятным причинам редкий.
  • Третий подход прокидываем имеющееся железо.

Про проблему со сканерами вы уже знаете: нужно ставить промежуточный софт на рабочую станцию (тонкий клиент), который получает поток USB, сжимает картинку и отправляет в VDI. В силу ряда особенностей, это не всегда возможно: если на Win-клиентах (домашних компьютерах и тонких клиентах) всё хорошо, то для *nix-сборок обычно вендором VDI поддерживается какой-то конкретный дистрибутив и начинаются танцы с бубном, как и на Mac-клиентах. На моей памяти мало кто подключал локальные принтеры с Linux-инсталляций так, чтобы они на этапе отладки работали без постоянных звонков в поддержку. Но это уже хорошо, некоторое время назад даже просто чтобы работали.

Видеоконференцсвязь все заказчики рано или поздно хотят, чтобы это работало и работало хорошо. Если правильно спроектировали ферму, то это работает хорошо, если неправильно получаем ситуацию, когда у нас во время аудиоконференции растёт нагрузка на канал, плюс дополнительно помимо этого возникает проблема того, что картинка отображается плохо (full HD нет, лицо из 916 пикселей). Возникает очень сильная дополнительная задержка, когда появляется петля между клиентом, рабочей станцией VDI, сервером ВКС, оттуда вторым VDI и вторым клиентом. Правильно соединять сразу с клиента на сервер ВКС, что требует установки ещё одного дополнительного компонента.

USB-ключи с ними вообще проблем нет, смарт-карты и подобное, всё работает из коробки. Сложности бывают со сканерами штрихкодов, принтерами этикеток, станками (да, было и такое), кассами. Но всё решается. С нюансами и не без сюрпризов, но в конечном счёте решается.

Когда пользователь смотрит Ютуб с VDI-станции это самая плохая ситуация и для нагрузки, и для канала. Большинство решений предлагает HTML5 видео редирекшн. Сжатый файл передают на клиента, там показывает. Или же клиенту передаётся ссылка для прямой связи браузера и видеохостинга (это реже).

Безопасность


Безопасность обычно искрит на месте стыков компонентов и на клиентских устройствах. На стыках в одной экосистеме на словах всё должно работать хорошо. На практике так бывает процентах в 90 % случаев, и что-то всё равно надо доделывать. В последние годы очень удобной оказалась ещё одна покупка Вмвары они взяли в экосистему MDM для управления устройствами внутри компании. У ВМов появились недавно интересные сетевые балансировщики (бывший Avi Networks), которые позволяют закрыть вопрос распределения потоков через год после сдачи VDI, например. Ещё одна чисто вмварная особенность хорошая оптимизация филиалов благодаря их свежему шопингу, когда они взяли компанию VeloCloud, которая делает SD-WAN для филиальных сетей.

С точки зрения конечного пользователя, архитектура и вендор почти незаметны. Глобально важно то, что есть клиент под любое устройство, с планшета, мака, вин-тонкого клиента можно подключиться. Были клиенты даже для телевизоров, но сейчас их уже, к счастью, нет.

Особенность VDI-инсталляций сейчас в том, что у конечного пользователя дома просто нет компьютера. Часто есть слабый андроид-планшет (иногда даже с мышью или клавиатурой), либо же может вообще повезти и получить компьютер на Win XP. Которая, как вы можете догадаться, некоторое время не обновлялась. И не обновится никогда уже. Либо очень слабые машины, где клиент не ставится, приложения не работают, пользователь не может работать. По счастью, даже очень слабые устройства подходят (не всегда комфортно, но подходят), и это считается большим плюсом VDI. Ну а относительно безопасности надо тестировать компрометацию клиентских систем. Это случается достаточно часто.

В свете рекомендаций Роспотребнадзора по организации работы предприятий в условиях риска COVID-19, подключение к своим рабочим местам в офисе очень актуально. Похоже, что эта история надолго, и да, если вы думали про VDI можно начинать тестировать. Пригодится. Рекомендации лежат вот здесь, разъяснения вот тут. Важно, что с помощью VDI также можно переоборудовать помещения для соблюдения требований. Регулятором вводятся определённые нормы дистанцирования. Например, в офисе площадью 50 кв. м не может находиться более пяти сотрудников.

Ну а если есть вопросы по VDI не для комментариев вот моя почта: SSkryl@croc.ru.
Подробнее..

Прячем RDP и быстро помогаем пользователям

30.06.2020 10:05:46 | Автор: admin
Дорогой читатель! Нам не терпится познакомить тебя с одной уникальной и полезной возможностью нашей системы управления ИТ инфраструктурой, которая делает трудолюбивых пользователей счастливыми, а лентяев и прогульщиков несчастными. За подробностями приглашаем по кат.

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

Подход Veliam к предоставлению удаленного доступа


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

Мы просто передаем пользователю один файл для подключения к удаленному ресурсу. Для удобства называем его Veliam Connector. Это исполняемый файл, после запуска которого пользователь вводит свои учетные данные и подключается туда, куда настроено в коннекторе. Подробно о принципе работы рассказано во второй части статьи про разработку системы.

Подключение происходит через наше облако и не требует настройки vpn, проброса портов, либо еще каких-то подобных технических решений. Мы снимаем с пользователя эти хлопоты. Рассказываем подробно, как это все организовать.

Удаленный доступ обычных сотрудников


Итак, представим, что у нас есть сервер терминалов, куда пользователи подключаются для работы в 1С. Отдельно у нас есть компьютер бухгалтера и юриста. Они не хотят работать полностью в терминале, предпочитая удаленно подключаться к своим рабочим компьютерам в офисе.

Нам нужно предоставить всем категориям пользователей удаленный доступ к ресурсам. Мы идем в клиент Veliam, откуда осуществляется управление системой. Переходим в раздел Удаленный доступ и создаем необходимые подключения.

Все предельно просто. Для того, чтобы настроить удаленное подключение, достаточно указать сервер мониторинга, через которое будет осуществляться подключение и адрес сервера терминалов. Он должен быть в сетевой доступности с сервером мониторинга.


Пароль можно не указывать, так как пользователь все равно будет вводить непосредственно свои учетные данные на самом сервере в момент RDP подключения. В данном случае пароль ограничивает инициализацию соединения через облако, организуя дополнительную защиту соединения.

Дополнительной полезной возможностью является то, что вы можете сразу же в момент создания ограничить срок действия настраиваемого подключения. Например, пользователь уходит в отпуск и хочет иметь возможность по необходимости удаленно подключаться. Вы сразу ставите срок действия подключения в 2 недели. В любой момент вы можете это изменить, либо полностью отключить доступ и ярлык перестанет работать.

После создания соединения, вам достаточно скачать ярлык для его использования и передать всем пользователям терминала.


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

Удаленное подключение пользователя


Для пользователей терминала ярлык может быть один и тот же, так как подключаются они к одному и тому же серверу. Отдельным сотрудникам нужно сделать индивидуальные ярлыки для подключения к своим компьютерам.

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

Удаленная работа с Veliam доступна пользователям с любым компьютером и доступом в интернет. В ближайшее время мы готовимся выпустить коннектор для операционной системы MacOS. В данный момент он существует только для ОС Windows.

Количество ярлыков, которые можно создать для удаленного доступа не ограничено. То есть использовать этот функционал можно совершенно бесплатно. Напоминаем, что система работает по принципу SaaS, а тарификация зависит от количества хостов сети, добавленных в мониторинг и пользователей системы HelpDesk. 50 хостов и пользователей входят в бесплатный тарифный план.

Удаленный доступ к серверам


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

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

Удаленное подключение к серверу


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

Удаленное подключение к серверу из заявки


Вы где-нибудь видели подобное удобство, организованное с такой же простотой? Мы нет. Напоминаем, что весь этот функционал вы можете попробовать абсолютно бесплатно.

Helpdesk система


Рассмотрим отдельно HelpDesk систему, которая вкупе с быстрым удаленным доступом, в том числе к компьютеру из заявки, делает систему Veliam целостным продуктом для управлением всей ИТ инфраструктурой.

Для HelpDesk системы вам необходимо через клиент создать сотрудников тех. поддержки и пользователей системы. Последние могут быть автоматически добавлены из AD. Для распределения доступа к заявкам и проектам сотрудников тех. поддержки используется ролевая модель доступа с гибкими настройками.

Как обычно в системе сделан акцент на простоту и удобство работы обычных пользователей. После добавления в систему, ему на почту приходит письмо со ссылкой на HelpDesk.


Не нужен ни логин, ни пароль. Вход сразу по ссылке. Тут же в письме можно сохранить ярлык на рабочий стол, по которому можно будет заходить в систему.

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


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


Работа технической поддержки с заявками


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


Внимание! Интересная возможность. Саппорт может сразу же из заявки подключиться к пользователю по VNC, в том случае, если у обоих он установлен в системе. У сотрудника server, у тех. поддержки viewer. Как обычно, соединение происходит через облако Veliam, так что не нужно дополнительно ничего настраивать для сетевой связности.

Прямое подключение из заявки


Помимо этого присутствует типовой набор возможностей классической HelpDesk системы. Заявку можно:

  1. отложить на какой-то срок;
  2. закрыть;
  3. изменить исполнителя;
  4. перенести в другой проект;
  5. написать сообщение пользователю;
  6. приложить файл и т.д.

Вот еще несколько полезных особенностей, которые есть не везде, но при этом они повышают удобство реальной эксплуатации:

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

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

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

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

Горшочек, вари серверный ARM-чип Marvell ThunderX3 с 96 ядрами и SMT4 для 384 потоков

30.06.2020 20:09:15 | Автор: admin

Недавно мы публиковали новость о 128-ядерном ARM-процессоре Altra Max. Также на Хабре упоминали серверные ARM-чипы, которые использует компания Amazon. Но, как оказалось, серверные процессоры c архитектурой ARM выпускают и другие компании.

Так, еще в конце марта этого года был анонсирован процессор Marvell ThunderX3, это новое поколение серверных чипов от компании Marvell. Производитель увеличил количество ядер в своих процессорах с 32 до 96, оставив поддержку SMT4, которая дает возможность обрабатывать четыре потока одним ядром. Соответственно, такой чип способен обрабатывать 384 потока.


По словам представителей компании, SMT4 гарантия того, что конвейеры отдельных ядер нагружаются эффективно. Новые процессоры при этом способны отлично работать не только в условиях многопоточных, но и однопоточных вычислений. Что касается односокетной конфигурации, то здесь поддерживаются 64 линии PCI Express 4.0 lanes, в двухсокетной число линий PCIe 4.0 увеличено до 128. В случае двухсокетных конфигураций процессоры соединяются через 16 линий PCI Express 4.0.


В отличие от прочих поставщиков ARM-чипов, предназначенных для серверов, компания Marvell использует не ARM Neoverse N1 архитектуру, а кастомную ARM8.3+. Информации о подсистеме кешей пока нет, но известно, что уровень латентности постоянен и не зависит от взаимного расположения ядер. А подсистема памяти аналогична Graviton2 и не включает восьмиканальный контроллер DDR4 с поддержкой частот до 3200 МГц.

Компания выпустит несколько вариантов ThunderX3 с теплопакетами от 100 до 240 Вт. По словам разработчиков, энергоэффективность новинки на треть превосходит AMD Rome (EPYC 2 поколения). Техпроцесс новинки TSMC 7 нм.


Источник. Двухсокетная конфигурация с процессорами предыдущего поколения Thunder X2.

Производительность чипа на 25% выше, чем у процессоров ThunderX2 предыдущего поколения. Это если говорить о многопоточном режиме работы. В однопоточном производительность увеличена на 60%. При этом с целочисленными операциями новинка справляется в три раза быстрее представителей предыдущего поколения, а с вычислениями с плавающей запятой в пять раз.


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

Судя по результатам тестов, новые чипы по ряду показателей обгоняют конкурентов от Intel и AMD. Но это внутрикорпоративные испытания, к которым, как известно, стоит относиться с осторожностью.

Процессоры все еще недоступны для сторонних экспертов, так что результатов независимых тестов пока нет. Выпустить новые процессоры компания собирается к концу 2020 года. Дополнительная информация будет предоставлена в августе. Ну уже сейчас компания заявила, что через два года выпустит новое поколение своих серверных процессоров.
Хотите попробовать сервер на ARM-процессоре уже сейчас?

Добро пожаловать в Selectel Lab!

Подробнее..

Путь разработчика в SRE зачем идти в инфраструктуру и что из этого выйдет

30.06.2020 20:09:15 | Автор: admin
Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.




В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

Предыстория: параллельные миры разработчиков и инфраструктуры


Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать через забор к команде инфраструктуры.

Чем лучше я понимал, в какой среде работает мой код, тем сильнее удивлялся: автоматические тесты на всё и вся, CI, частые релизы, безопасный рефакторинг и коллективное владение кодом в мире софта уже давно обыденны и привычны. При этом в мире инфраструктуры до сих пор нормально отсутствие автоматических тестов, внесение изменений в продакшн системы в полуручном режиме, а документация часто есть только в головах отдельных людей, но не в коде.

Этот культурный и технологический разрыв вызывает не только недоумение, но и проблемы: на стыке разработки, инфраструктуры и бизнеса. С частью проблем в инфраструктуре сложно бороться из-за близости к железу и относительно слабо развитых инструментов. Но остальное вполне можно победить, если начать смотреть на все свои Ansible-плейбуки и Bash-скрипты как на полноценный программный продукт и применять к ним те же требования.

Бермудский треугольник проблем


Однако я начну издалека с проблем, ради которых все эти пляски нужны.

Проблемы разработчиков


Два года назад мы поняли, что большая сеть пиццерий не может жить без собственного мобильного приложения и решили его написать:

  • собрали классную команду;
  • за полгода написали удобное и красивое приложение;
  • подкрепили торжественный запуск вкусными промоакциями;
  • и в первый же день благополучно упали под нагрузкой.



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

Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном некритичного сервиса обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:
Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.

Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOpsами/SRE. В итоге программисты:

Зависят от команды инфраструктуры. Это вызывает боль, недопонимание, иногда взаимную ненависть.

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

Не понимают природу багов и проблем, связанных с их кодом. Особенно это заметно, когда проблемы связаны с нагрузкой, балансировкой запросов, сетью или производительностью жёстких дисков. Разработчики не всегда располагают этими знаниями.

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

Проблемы инфраструктуры


Сложности есть и на другой стороне.

Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

  • 60 ролей;
  • 102 плейбука;
  • обвязка на Python и Bash;
  • тесты в Vagrant, запускаемые вручную.

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

Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или некогда запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.

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

Проблемы бизнеса


У бизнеса тоже есть две большие проблемы, которые нужно решать.

Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, подсчитать невозможно, в деньгах это не оценивается.

Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:

  • с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
  • с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
  • с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?


Как решить все эти проблемы? Решение мы нашли в книге Site Reliability Engineering от Google. Когда прочли, поняли это то, что нам нужно.

Но есть нюанс чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

Из хороших практик SRE у нас уже были:

  • механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
  • процессы для дежурств 24/7 on-call;
  • практика ведения постмортемов по инцидентам и их анализ;
  • нагрузочное тестирование;
  • CI/CD-пайплайны для прикладного софта;
  • хорошие программисты, которые пишут хороший код;
  • евангелист SRE в команде инфраструктуры.

Но были и проблемы, которые хотелось решить в первую очередь:

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

Хаос в коде. Инфраструктурный код был хаотичен, разбросан по разным репозиториям и нигде не задокументирован. Всё держалось на знаниях отдельных людей и больше ни на чём. Это была гигантская проблема управления знаниями.

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

Онбординг SRE-команды


Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов первый шаг к полноценной структуре SRE.

На проект мы выделили 4 месяца и поставили три цели:

  1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
  2. Написать IaC описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
  3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Состав участников: 9 человек, 6 из них из команды разработки, 3 из инфраструктуры. На 4 месяца они должны были уйти из обычной работы и погрузиться в обозначенные задачи. Чтобы поддерживать жизнь в бизнесе, ещё 3 человека из инфраструктуры остались дежурить, заниматься операционкой и прикрывать тылы. В итоге проект заметно растянулся и занял больше пяти месяцев (с мая по октябрь 2019-го года).

Две составляющие онбординга: обучение и практика


Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

Обучение. На обучение выделялось минимум 3 часа в день:

  • на чтение статей и книг из списка литературы: Linux, сети, SRE;
  • на лекции по конкретным инструментам и технологиям;
  • на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Ещё один инструмент обучения внутреннее демо. Это еженедельная встреча, на которой каждый (кому есть, что сказать) за 10 минут рассказывал о технологии или концепции, которую он внедрил в нашем коде за неделю. Например, Вася поменял пайплайн работы с Terraform-модулями, а Петя переписал сборку образов на Packer.

После демо мы заводили обсуждения под каждой темой в Slack, где заинтересованные участники могли асинхронно обсуждать всё детальнее. Так мы избегали длинных встреч на 10 человек, но при этом все в команде хорошо понимали, что происходит с нашей инфраструктурой и куда мы катимся.



Практика. Вторая часть онбординга создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.



Реверсинжиниринг инфраструктуры. Это первый этап, на котором разобрали, что где задеплоено, как что работает, где какие сервисы работают, где какие машины и их размеры. Всё полностью задокументировали.

Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.

Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

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

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

Наши инструменты для IaC
  • Terraform для описания текущей инфраструктуры.
  • Packer и Ansible для создания образов виртуальных машин.
  • Jsonnet и Python как основные языки разработки.
  • Облако Azure, потому что у нас там хостинг.
  • VS Code IDE, для которой создали единые настройки, расширенный набор плагинов, линтеров и прочего, чтобы писать унифицированный код и расшарили их между всеми разработчиками.
  • Практики разработки одна из основных вещей, ради которой затевался весь этот карнавал.


Практики Extreme Programming в инфраструктуре


Главное, что мы, как программисты, принесли с собой это практики Extreme Programming, которые используем в работе. XP гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.

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

О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.

Всё могло бы сложиться хорошо, но так не бывает.

Технические и антропогенные проблемы на пути


В рамках проекта было два вида проблем:

  • Технические: ограничения железного мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
  • Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

Мы начали развивать команду онбординга так, как стали бы делать это с любой другой командой программистов. Мы ожидали, что будут обычные стадии формирования команды по Такману: шторминг, норминг, а в конце мы выйдем на производительность и продуктивную работу. Поэтому не переживали, что вначале возникали какие-то сложности в общении, принятии решений, сложности с тем, чтобы договориться.

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

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

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

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

Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта что больше нравится. Возможно, они помогут.

Итоги онбординга


По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

  • Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
  • Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
  • Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
  • Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли


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

Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

Примерно так же я ощущаю себя сейчас, когда работаю с инфраструктурой. Текущие инструменты только формируются, многие из них ещё не вышли в релиз и имеют версию 0.12 (привет, Terraform), а у многих регулярно ломается обратная совместимость с предыдущими версиями.

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

Читайте документацию. Как программист, я относительно редко обращался к докам. Я достаточно глубоко знал свои инструменты: любимый язык программирования, любимый фреймворк и БД. Все дополнительные инструменты, например, библиотеки, обычно написаны на том же языке, а значит всегда можно посмотреть в исходники. IDE всегда подскажет, какие и где нужны параметры. Даже если я ошибусь, то быстро это пойму, запустив быстрые тесты.

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

Комментарии в коде инфраструктуры неизбежны. В мире разработки комментарии признак плохого кода. Они быстро устаревают и начинают врать. Это признак того, что разработчик не смог иначе выразить свои мысли. При работе с инфраструктурой комментарии так же признак плохого кода, но без них уже не обойтись. Для разрозненных инструментов, которые слабо связаны друг с другом и ничего не знают друг о друге, без комментариев не обойтись.

Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

PS: Я специально не стал затрагивать в этой статье темы микросервисов, Кубернетеса и прочие хайповые вещи, с которыми приходится учиться жить, так как это большая тема для отдельной статьи.

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится два блока по два дня и домашние задания между ними.

Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.
Подробнее..

Интеграция Open vSwitch с Р-виртуализацией

01.07.2020 10:24:00 | Автор: admin

Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.


Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.



Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.


Железо


Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.


Развертывание РП


Краткая инструкция по установке:


  • 1. Устанавливаем первую ноду, в анаконде назначаем IP хосту и из этой же подсети виртуальный IP для управления Р-виртуализации, и IP для управления Р-хранилищем. Дисков как минимум должно быть 3, один для хоста (ОС/гипервизор) в моем случае HDD, второй и третий диск уже настроим через управление Р-хранилищем, где один SSD под кэш и другой под чанк сервер. На втором интерфейсе назначаем IP из другой подсети для сети хранения без шлюза.
  • 2. После установки заходим через браузер хром по IP адресу управления Р-хранилищем, далее выбираем раздел серверы и нажимаем на вопросик с прямоугольником, и выбираем раздел сеть, в нем назначаем роли для интерфейса с адресом подсети управления(роли ssh, управление, web cp) и для интерфейса с подсетью для хранения назначаем роли (ssh, хранилище).
  • 3. Далее нажимаем создать кластер вводим его имя автоматом должен подключится интерфейс с ролью хранения и выбрать подробные настройки, убедится что система правильно распределила роли на дисках, один должен быть системный, другой служба метаданных плюс кэш если это SSD и далее третий диск HDD в роли хранения (чанк сервер).
  • 4. Параллельно с установкой первой ноды можно устанавливать две последующие, назначить каждой по два IP адреса один для подсети управления Р-виртуализации, на втором интерфейсе из подсети хранения. Если оставить поля регистрации на сервере управления Р-виртуализации и управления Р-хранилище пустыми то, можно продолжить установку без указания IP адресов управления, а регистрацию выполнить потом.
  • 5. После того как последующие ноды установлены пройти по IP адресу этих хостов через ssh в cli и выполнить регистрацию, где IP это адрес управления Р-хранилищем и токен можно скопировать с веб управления р-хранилищем при нажатии добавить ноду.
  • 6. После того как обе ноды появятся в веб управлениии Р-хранилище выполнить те же действия что в пункте 2-3 только вместо создания кластера выбрать присоединить.
  • 7. Далее после создания кластера появится пункт сервисы в нем создать хранилище датастор в зависимости наличия дисков и узлов можно делать реплику 2 или 3 и т.д. если узла 3 то, реплика 2, остальное все по умолчанию.
  • 8. Далее проходим по IP адресу управления Р-виртуализации нажимаем добавить если физ. сервер если не добавлен и добавляем остальные, далее устанавливаем триал лицензию, далее в настройках хоста выполнить Изменение настроек хоста для виртуальных сред выбрать вместо локальной папки по умолчанию можно для всех пунктов(для первого раза лучше так) выбираем наш датастор который создавали в Р-хранилище и ставим галочку применить на все хосты.
  • 9. После это мигрируем vstorage-ui и va-nm на любой другой хост, время может занять некоторое потому что это миграция с локальных носителей на кластерные.
  • 10. После этого открываем ssh консоли всех трех узлов и вводим команду включения HA на каждом узле, где IP адрес сети хранения, после этого необходимо проверить командой #shaman stat
  • 11. После этого можно приступать к созданию ВМ, где я в качестве гостевой установил CentOS 7.

команда регистрации ноды к выше описанному пункту 5:


#/usr/libexec/vstorage-ui-agent/bin/register-storage-node.sh -m 10.43.10.14 -t ec234873

комнда включения HA к пункту 10:


#hastart -c имя кластера -n 192.168.10.0/24 

и проверка HA, где вывод должен быть примерно такой:


[root@n3 ~]# shaman statCluster 'rptest'Nodes: 3Resources: 7    NODE_IP           STATUS     ROLES                RESOURCES    192.168.10.10     Active     VM:QEMU,CT:VZ7       0 CT, 0 VM    192.168.10.11     Active   VM:QEMU,CT:VZ7       0 CT, 0 VM*M 192.168.10.12     Active     VM:QEMU,CT:VZ7       2 CT, 0 VM

Установка и настройка OVS


На первой и третей ноде кластера были установлены OVS следующей командой:


#yum install openvswitch 

После установки можно проверить командой


#ovs-vsctl show 

Вывод будет примерно следующий:


[root@node1 ~]# ovs-vsctl show180c5636-2d3d-4e08-9c95-fe5e47f1e5faovs_version: "2.0.0"[root@node1 ~]#

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


# ovs-vsctl add-br ovsbr0 

Имя моста назовем так чтобы было понятно, что это экземпляр одного виртуального коммутатора.
Далее можем создать тегированный мост для добавления к определенной ВМ.


#ovs-vsctl add-br brlv140 ovsbr0 140 

Тег при этом может быть не привязан к какому-то реальному тегу с физического порта, это только в рамках виртуального коммутатора.
Далее назначаем его ВМ к виртуальной сети, где предварительно создаем xml файл:


<network> <name>ovsvl</name> <forward mode='bridge'/> <bridge name='brlv140'/> <vlan>  <tag id='140'/></vlan><virtualport type='openvswitch'/></network>

К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:


#virsh net-list --all 

Для добавления нашей сети:


#virsh net-define ovsvl.xml 

Далее необходимо ее запустить/активировать


#virsh net-start ovsvl

И прописать в автостарт


#virsh net-autostart ovsvl

Далее необходимо добавить эту сеть к ВМ


#virsh edit имяВМ 

Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):


<interface type='bridge'>      <mac address='00:1c:42:c6:80:06'/>

  <vlan>    <tag id='140'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='5a70be5b-5576-4734-9f61-61cdfc4a884a'/>  </virtualport>  <target dev='vme001c42c68006'/>  <model type='virtio'/>  <boot order='2'/>  <alias name='net0'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></interface>


Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:


#prlctl stop имя ВМ

#prlctl start имя ВМ

Для проверки можно ввести команду:


#virsh dumpxml имяВМ | grep имясети 

После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.12 

где IP адрес это адрес той ноды на которой произведены такие же настройки как показано выше. Прямая связь между этими адресами может быть, как через роутеры, так и через VPN, и из разных подсетей, главное, чтобы между ними был настроен маршрут. Но еще главнее, чтобы интерфейс физического порта на котором назначен это адрес, был настроен MTU больше чем 1500 для пропускания пакетов с большим размером, так как vxlan добавляет свои данные, заголовок в несколько байт, но я не стал заморачиваться считать все байты и просто назначил 2000.
Например:


#ip link set mtu 2000 dev ens3f0

сам мост зависящий от этого интерфейса тоже должен быть с mtu2000, но он может не сразу его наследовать и возможно понадобиться его перезапустить.


На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.10

Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:


#tcpdump i ens3f0 | grep 4789``` то можно увидеть пакеты с vxlan или c тегами vlan ```bash#tcpdump -ee -vvv -i ens3f0 | grep vlan

Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:


 <network><name>ovsvl2</name><forward mode='bridge'/><bridge name='ovsbr0'/><virtualport type='openvswitch'/><portgroup name='vlan-120'>    <vlan>      <tag id='120'/>    </vlan>  </portgroup></network>

Можно создать новую сеть или отредактировать предыдущую с этими параметрами, но
В моем случае добавляю еще одну сеть
Как описано выше, а в ВМ уже следующим образом:


<interface type='bridge'>      <mac address='00:1c:42:c8:f1:cd'/>

  <vlan>    <tag id='120'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='ef717aa4-23b3-4fbe-82bb-193033f933b1'/>  </virtualport>  <target dev='vme001c42c8f1cd'/>  <model type='virtio'/>  <boot order='3'/>  <alias name='net1'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/></interface>


Далее сохранить и перезапустить ВМ как описано выше, а на одном из виртуальных коммутаторов можно добавить транковый порт с определенными тегами от физического порта, то есть предварительно с подключенным на один из физических портов сервера с транковым тегированным трафиком от физического коммутатора.
В моем случае:


#ovs-vsctl set port ens3f4 trunks=120,130#ovs-vsctl add-port ovsbr0 ens3f4  

И можно добавить порт с тегом 120 для ВМ:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

На стороне другого виртуального коммутатора на другой ноде другого кластера, где нет транка от физического коммутатора добавить точно также этот порт то есть:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

Плюс добавить сеть как описано выше.


Пример вывода настроек OVS и ВМ



Вывод команды #ovs-vsctl show на первой ноде. Порты и интерфейсы с именем начинающимся с vme являются виртуальными интерфейсами ВМ, которые автоматически попадают в конфиг при запуске ВМ подключенному к OVS.



Вывод команды #ovs-vsctl show на третей ноде



Вывод команды virsh net-list содержит 4 вида сети, где Bridged и Host-Only это стандартные классические варианты от Р-виртуализации по дефолту, а ovsvl и ovsvl2 это то, что мы добавили по инструкции выше. Ovsvl получается для варианта с тегированным мостом tag 140 поверх моста OVS, а ovsvl2 это вариант с группой портов portgroup состоящей из одного порта с tag 120. Portgroup очень удобен и в него можно добавлять больше одного порта используя только одну сеть вместо большого количества сетей в классическом варианте Р-виртуализации с мостами под которыми разные VLAN интерфейсы. Далее вывод команды #virsh net-dumpxml ovsvl и ovsvl2 показывающие содержимое настроек этих сетей.



Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:


 #virsh dumpxml имяВМ

Тесты


При тестировании OVS была проверена совместимость с запущенным networkmanager(NM), выше описанные сценарии работают нормально, но при автозапуске службы NM может выдавать сообщения по интерфейсам виртуального коммутатора, которыми не может управлять, NM можно выключить, но на функциональность сети это не влияет.


Еще имеются дополнения для управления OVS через NM, но в этом случае функционал OVS ограничен. Поэтому возможна параллельная работа, либо с отключением NM при необходимости.


Также были успешно проверены живые миграции ВМ с сетями от OVS, если на каждой ноде имеется экземпляр сети вместе с OVS то, проблем с миграцией нет, так же как и в стандартной конфигурации кластера Р-виртуализации с дополнительными сетями для ВМ.



На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.


Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.


По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.


Описание сценариев


Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.



На схеме опущена и не показана сеть Р-хранилища, она обычно идет отдельным интерфейсом предназначенного только для блочного уровня и в этом тесте не участвует. Ее можно настраивать без мостов, и как вариант ее тоже можно задействовать через OVS. Например настроить на OVS агрегацию для Р-хранилища.
Далее схема с использованием вместе с мостами OVS.



Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.


Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке



В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.


Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища. Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.


Как работает классический br0 я описывать не буду, ovsbr0 работает со IP стеком ОС, который на этой картинке определен для br0, то есть экземпляр виртуального коммутатора в виде ovsbr0 работает в данном случае через br0. Другими словами статический IP адрес ноды назначен на классический br0 и весь трафик, который направлен в эту подсеть с виртуального коммутатора проходит через br0, так же как это работает для всех приложений этой ноды. С точки зрения настройки в этом случае никаких cli назначений на br0 со стороны виртуального коммутатора не производилось кроме настройки vxlan интерфейса с option, соответственно если у ноды есть второй классический br1 c другим IP адресом и подсетью висящий на другом физическом порту например eth2 или eth3 то, с виртуального коммутатора за счет стека ОС и его таблицы mac-ов можно направить пакеты в эти подсети назначив какой либо порт виртуального коммутатора в эту подсеть и подключить к ВМ, адрес подсети будет непосредственно назначаться внутри ВМ или в ее настройках.


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



У виртуального коммутатора есть своя таблица маков.


У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.


Теоретически мы можем представить, что когда в какой-то порт коммутатора прилетает фрейм с VLAN тегом, то решение о дальнейшей отправке фрейма принимается на основании таблицы mac адресов соответствующего виртуального коммутатора. Если получен фрейм с тегом 120, то соответственно приниматься решение о форвардинге данного фрейма будет на основании mac таблицы виртуального коммутатора с тегом 120.


Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее VxLAN тоннель коммутатор воспринимает как простой транковый порт.


Минусы данного подхода очевидны это увеличенная нагрузка на сеть, так как BUM трафик реплицируется на исходящем интерфейсе vxlan и юникастом рассылается всем указанным в конфигурации нейборам, плюс к этому при добавлении или удалении интерфейса vxlan придется править конфиги на всех остальных интерфейсах vxlan-ах и руками удалить или добавить нейбора (нейборов) или в авторежиме средствами скриптов шамана в случае аварии узла. В век автоматизации конечно как-то странно использовать статическое указание нейборов. Но все равно данный подход имеет право на жизнь, например OVS умеет работать только со статически заданным нейбором, во всяком случае на данный момент.


Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.


Заключение


При выполнении настроек OVS понравилась простота, удобносто, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.


Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
1)https://www.sidorenko.io/post/2018/11/openstack-networking-open-vswitch-and-vxlan-introduction/
2) https://blog.remibergsma.com/2015/03/26/connecting-two-open-vswitches-to-create-a-l2-connection/
3)http://mx54.ru/nastrojka-setevyx-interfejsov-v-kvm-dlya-virtualnyx-mashin/
4) https://kamaok.org.ua/?p=2677
5)https://kashyapc.fedorapeople.org/virt/add-network-card-in-guest.txt
6)https://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/#.XuZ960UzaM_

Подробнее..

Обзор IP телефона Snom D725 или когда нужно много физических кнопок

01.07.2020 10:24:00 | Автор: admin
Здравствуйте дорогие читатели!
Мы продолжаем обзор модельного ряда IP-телефонов Snom и сегодня подготовили для вас обзор на телефон с наибольшим количеством физических функциональных клавиш из нашей линейки модель Snom D725.

image

Распаковка и комплектация


Как и всегда в наших обзорах, рассмотрим комплектацию и упаковку аппарата. Коробка достаточно компактна, на ней присутствует информация о модели и версии ПО телефона. Комплектация включает в себя:
  • Телефонный аппарат
  • Краткое руководство пользователя
  • Подставку
  • Ethernet-кабель категории 5E
  • Трубку и витой шнур для ее подключения


image

Дизайн


Рассмотрим телефон поближе. Основная особенность аппарата большое количество BLF-клавиш, их здесь 18. Большая часть современных телефонов использует несколько страниц экрана для мониторинга состояния столь большого количества абонентов, но, давайте будем честны, мало кто в этом случае использует все страницы из-за необходимости перелистывания, а в данном случае все абоненты всегда на виду каждый на своей клавише. Минусом такого устройства является необходимость вручную подписывать название клавиш, зато пользователь телефона однозначно запомнит расположение номеров абонентов на этих самых клавишах и сможет найти нужную ему кнопку очень быстро.

image

Корпус аппарата выполнен в классическом черном цвете, пластик корпуса приятный на ощупь, чуть шершавый, не маркий. Клавиш на корпусе большое количество, даже не считая BLF-кнопок, однако расположены они очень компактно, благодаря чему и сам телефон имеет достаточно скромные размеры.

image

Экран на данном аппарате черно-белый, с крупным шрифтом и яркой подсветкой. Под экраном размещены четыре подэкранные функциональные клавиши, чуть ниже клавиши навигации. Джойстик на этом телефоне выполнен в виде круглой клавиши с четырьмя направлениями нажатия, слева и справа от него находятся кнопки подтверждения и отмены. Справа от последней, находится клавиша записи. Клавиши этого блока расположены достаточно разряжено, для удобства управления телефоном.
Чуть ниже находятся уже упомянутые восемнадцать BLF-клавиш. Они занимают центральную часть лицевой панели аппарата и расположены так, чтобы постоянно быть в поле зрения пользователя на виду. Так сотрудник всегда будет видеть состояние важных для него абонентов и, при необходимости сможет перевести или перехватить важный звонок.

image

Разъемы телефона находятся на его задней панели. Здесь расположились: 4-х пиновый разъем микролифта EHS, гигабитные порты PC и NET, разъем блока питания, порты трубки и гарнитуры и USB-порт. Доступ к большей части из них осуществляется снизу под подставкой.
Сама по себе подставка двухпозиционная, в зависимости от стороны крепления к телефону она обеспечивает углы наклона корпуса в 46 или 28 градусов, позволяя пользователю расположить корпус телефона удобно для своего зрения.

Программное обеспечение и настройка


image
Интерфейс настройки телефонного аппарата прост. По умолчанию в нем нет ярких цветов основное здесь функциональность и простота настройки. Однако, если вам это необходимо вы можете изменить его, использовать свою цветовую гамму или изменить иконки. О том, как это сделать читайте в наших статьях.
BLF-клавиши D725 не имеют преднастройки, но сам процесс настройки клавиш очень и очень лаконичен. Пользователю лишь необходимо зажать на несколько секунд нужную ему клавишу, после чего достаточно выбрать функцию для клавиши из внушительного списка предложенных и заполнить нужные для ее работы поля, например, указать номер абонента для мониторинга его состояния с помощью BLF.

Функционал и эксплуатация


Включаем телефон и еще раз обратим внимание на дисплей. Он более чем гармонично вписывается в дизайн аппарата, отображая всю необходимую информацию и не отвлекая от главного BLF-клавиш.
Клавиши расположены достаточно близко чтобы не занимать много места и достаточно далеко, чтобы при нажатии на одну из них, пользователь не задевал соседние клавиши. Нажатие на клавиши приятное, мягкое, с четкой обратной связью. Индикация обращает на себя внимание, но не слепит и не рябит, взгляд не устает следить за изменением индикации клавиш.

image

У большей части телефонов Snom отсутствует курок отбоя, D725 здесь не стал исключением, физический курок заменен на электронный. Избавление от механической детали повышает надежность, сама трубка при этом лежит на аппарате куда плотнее, удерживаемая резиновыми уплотнителями, а ложится мягко и предсказуемо.
Начинка трубки дорабатывалась нашей компанией в акустической лаборатории, и это ощущается при использовании телефона по его основному назначению. Звук плотный, четкий и в меру громкий, различимы все интонации собеседника. На другом конце вас также хорошо слышно микрофон прекрасно захватывает голос и собеседникам вашего сотрудника, будь то секретарь или менеджер, не придется напрягать слух при общении.

image

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

Аксессуары


Как уже было сказано выше, на телефоне присутствует USB-разъем. Он используется для подключения USB-гарнитуры, флеш-накопителя, DECT донгла A230, Wi-Fi-модуля A210, а также панели расширения D7. Обратим внимание на последние.
Панель расширения D7 заметно увеличит и без того не малое количество BLF-клавиш, доступных для настойки на телефоне. Каждая из панелей предлагает пользователю еще 18 дополнительных клавиш, а всего к одному аппарату можно подключить до 3-х панелей, добавив к клавишам телефона еще 54 клавиши.
image
DECT-донгл A230 позволяет подключить к аппарату DECT-гарнитуру, увеличив мобильность сотрудника, либо же использовать внешний динамик Snom C52 SP, что позволяет использовать аппарат в большом кабинете или небольшой переговорной комнате.
Wi-Fi-модуль A210 используется для подключения к беспроводным сетям Wi-Fi. Модуль работает и с сетями 2.4 Ггц, и 5 Ггц, что позволяет подключать телефон к современным сетям связи компании.

Подведем итог


Snom D725 телефон с большим количеством клавиш и хорошим звуком. Для кого он подойдет? Вероятнее всего для секретарей, менеджеров и других сотрудников, использующих большое количество функциональных клавиш в своей работе. Он полностью выполняет заложенные в него функции, позволяет производить простую настройку и послужит хорошим товарищем в буднях ваших коллег.
Подробнее..

Из песочницы Опыт эксплуатации CEPH

01.07.2020 12:12:44 | Автор: admin
Когда данных становится больше, чем влезает на один диск, самое время задуматься о RAID. В детстве часто слышал от старших: однажды RAID уйдут в прошлое, объектные хранилища заполонят мир, а ты даже не знаешь, что такое CEPH,- поэтому первым делом в самостоятельной жизни стало создание своего кластера. После нескольких лет эксплуатации и пары необратимых потерь данных возникло понимание тонкостей, что не всё так однозначно. Особенности CEPH препятствуют его широкому распространению, и из-за них эксперименты зашлив тупик. Ниже приводится описание всех пройденных шагов, полученный результат и сделанные выводы. Если знающие люди поделятся опытом и пояснят некоторые моменты буду благодарен.

Стратегия CEPH


Кластер CEPH объединяет произвольное количество K дисков произвольного размера и хранит данные на них, дублируя каждый кусочек (4 МБ по умолчанию) заданное число N раз.

Рассмотрим простейший случай с двумя одинаковыми дисками. Из них можно либо собрать RAID 1, либо кластер с N=2 результат получится один и тот же. Если дисков три, и они разного размера, то собрать кластер с N=2 легко: часть данных будут на дисках 1 и 2, часть на 1 и 3, а часть на 2 и 3, тогда как RAID нет (можно собрать такой RAID, но это будет извращением). Если дисков ещё больше, то возможно создание RAID 5, у CEPH есть аналог erasure_code, который противоречит ранним концепциям разработчиков, и поэтому не рассматривается. RAID 5 предполагает, что имеется небольшое количество дисков, и все они в хорошем состоянии. При отказе одного, остальные должны продержаться до момента, пока не заменят диск и не будут восстановлены на него данные. CEPH же, при N>=3, поощряет использование старых дисков, в частности, если держать несколько хороших дисков для хранения одной копии данных, а оставшиеся две-три копии хранить на большом количестве старых дисков, то информация будет в сохранности, так как пока живы новые диски проблем нет, а если один из них сломается, то одновременный отказ трёх дисков со сроком службы более пяти лет, желательно, из разных серверов событие крайне маловероятное.

В распределении копий есть тонкость. По умолчанию подразумевается, что данные делятся на больше количество (~по 100 на диск) групп распределения PG, каждая из которых дублируется на каких-то дисках. Допустим, K=6, N=2, тогда при выходе из строя двух любых дисков, гарантированно теряются данные, так как по теории вероятности, найдётся хотя бы одна PG, которая расположится именно на этих двух дисках. А потеря одной группы делает недоступными все данные в пуле. Если же диски разбить на три пары и разрешить хранить данные только на дисках внутри одной пары, то такое распределение также устойчиво к отказу одного любого диска, зато при отказе двух вероятность потери данных не 100%, а всего 3/15, и даже при отказе трёх дисков только 12/20. Отсюда, энтропия в распределении данных не способствует отказоустойчивости. Также заметим, что для файлового сервера свободная оперативная память значительно увеличивает скорость отклика. Чем больше памяти в каждом узле, и чем больше памяти во всех узлах тем будет быстрее. Это несомненно преимущество кластера перед одиночным сервером и, тем более, аппаратным NAS-ом, куда встраивают очень малый объём памяти.

Отсюда следует, что CEPH хороший способ с минимальными вложениями из устаревшего оборудования создать надёжную систему хранения данных на десятки ТБ с возможностью масштабирования (тут, конечно, потребуются затраты, но небольшие по сравнению с коммерческими СХД).

Реализация кластера


Для эксперимента возьмём списанный компьютер Intel DQ57TM + Intel core i3 540 + 16 ГБ ОЗУ. Четыре диска по 2 ТБ организуем в подобие RAID10, после успешного испытания добавим второй узел и ещё столько же дисков.

Устанавливаем Linux. От дистрибутива требуется возможность кастомизация и стабильность. Под требования подходят Debian и Suse. У Suse более гибкий установщик, позволяющий отключить любой пакет; к сожалению, я не смог понять, какие можно выкинуть без ущерба для системы. Ставим Debian через debootstrap buster. Опция min-base устанавливает нерабочую систему, в которой не хватает драйверов. Разница в размере по сравнению с полной версией не так велика, чтобы заморачиваться. Поскольку работа ведётся на физической машине, хочется делать снапшоты, как на виртуалках. Такую возможность предоставляет либо LVM, либо btrfs (или xfs, или zfs разница не велика). У LVM снапшоты не сильная сторона. Ставим btrfs. И загрузчик в MBR. Нет смысла засорять диск 50 МБ разделом с FAT, когда можно затолкать его в 1 МБ область таблицы разделов и всё пространство выделить под систему. Заняло на диске 700 МБ. Сколько у базовой установки SUSE не запомнил, кажется, около 1.1 или 1.4 ГБ.

Устанавливаем CEPH. Игнорируем версию 12 в репозитории debian и подключаем прямо с сайта 15.2.3. Следуем инструкции из раздела устанавливаем CEPH вручную со следующими оговорками:

  • Перед подключение репозитория необходимо установить gnupg wget ca-certificates
  • После подключения репозитория, но перед установкой кластера опущена установка пакетов: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
  • В момент установки CEPH по непонятным причинам будет пытаться установиться lvm2. В принципе, не жалко, но установка завершается сбоем, поэтому CEPH тоже не установится.

    Помог этот патч:
    cat << EOF >> /var/lib/dpkg/statusPackage: lvm2Status: install ok installedPriority: importantSection: adminInstalled-Size: 0Maintainer: Debian Adduser Developers <adduser@packages.debian.org>Architecture: allMulti-Arch: foreignVersion: 113.118Description: No-installEOF
    


Обзор кластера


ceph-osd отвечает за хранение данных на диске. Для каждого диска запускается сетевая служба, которая принимает и исполняет запросы на чтение или запись в объекты. На диске создаётся два раздела. Один из них содержит информацию о кластере, номере диска, а также ключи от кластера. Эта информация объёмом 1КБ один раз создаётся при добавлении диска и больше никогда не замечал, чтобы менялась. На втором разделе нет файловой системы и хранятся двоичные данные CEPH. Автоматическая установка в предыдущих версиях создавала xfs раздел размером 100МБ для служебной информации. Я сконвертировал диск в MBR и выделил всего на 16МБ служба не жалуется. Думаю, без проблем xfs можно было бы заменить и на ext. Этот раздел монтируется в /var/lib/..., где служба считывает информацию об OSD, а также находит ссылку на блочное устройство, где хранятся двоичные данные. Теоретически, можно сразу вспомогательные расположить в /var/lib/..., а диск целиком выделить под данные. При создании OSD через ceph-deploy автоматически создаётся правило для монтирования раздела в /var/lib/..., а также назначаются права пользователю ceph на чтение нужного блочного устройства. При ручной установке это необходимо сделать самому, в документации об этом не сказано. Также желательно указать параметр osd memory target, чтобы хватило физической памяти.

ceph-mds. На низком уровне CEPH объектное хранилище. Возможность блочного хранения сводится к сохранению каждого блока 4МБ в виде объекта. По тому же принципу работает и файловое хранение. Создаётся два пула: один для метаданных, другой для данных. Они объединяются в файловую систему. В этот момент создаётся какая-то запись, поэтому если удалить файловую систему, но сохранить оба пула, то восстановить её не получится. Есть процедура по извлечению файлов по блокам, не тестировал. За доступ к файловой системе отвечает служба ceph-mds. Для каждой файловой системы необходим отдельный экземпляр службы. Есть опция индекс, которая позволяет создать подобие нескольких файловых систем в одной тоже не тестировалось.

сeph-mon эта служба хранит карту кластера. В неё входит информация обо всех OSD, алгоритм распределения PG в OSD и, самое главное, информация обо всех объектах (детали этого механизма мне непонятны: есть каталог /var/lib/ceph/mon/.../store.db, в нём лежит большой файл 26МБ, а в кластере 105К объектов, получается чуть более 256 байт на объект,- я думаю, что монитор хранит список всех объектов и PG, в которых они лежат). Повреждение этого каталога приводит к потере всех данных в кластере. Отсюда и сделан вывод, что CRUSH показывает как PG расположены по OSD, а как объекты расположены по PG централизованно хранятся внутри базы данных, как бы разработчики не избегали этого слова. Как следствие, во-первых, мы не можем установить систему на флешку в режиме RO, так как в базу данных ведётся постоянная запись, необходим дополнительный диск под эти (вряд ли более 1 ГБ), во-вторых, необходимо в реальном времени иметь копию этой базы. Если мониторов несколько, то отказоустойчивость обеспечивается автоматически, но в нашем случае монитор один, максимум два. Есть теоретическая процедура восстановления монитора на основе данных OSD, трижды прибегал к ней по разным причинам, и трижды никаких сообщений об ошибках, как и данных тоже. К сожалению, этот механизм не работает. Либо мы эксплуатируем миниатюрный раздел на OSD и собираем RAID для хранения базы данных, что наверняка очень плохо скажется на производительности, либо выделяем хотя бы два надёжных физических носителя, желательно, USB, чтобы порты не занимать.

rados-gw экспортирует объектное хранилище по протоколу S3 и подобные. Создаёт множество пулов, непонятно зачем. Особо не экспериментировал.

ceph-mgr при установке этой службы запускаются несколько модулей. Один из них не отключаемый autoscale. Он стремится поддерживать правильное количество PG/OSD. При желании управлять соотношением вручную, можно запретить масштабирование для каждого пула, но в таком случае модуль падает с делением на 0, и статус кластера становится ERROR. Модуль написан на питоне, и если закомментировать в нём нужную строчку, это приводит к его отключению. Детали лень вспоминать.

Список использованных источников:

Установка CEPH
Восстановление при полном отказе монитора

Листинги скриптов:

Установка системы через debootstrap
blkdev=sdb1mkfs.btrfs -f /dev/$blkdevmount /dev/$blkdev /mntcd /mntfor i in {@,@var,@home}; do btrfs subvolume create $i; donemkdir snapshot @/{var,home}for i in {var,home}; do mount -o bind @${i} @/$i; donedebootstrap buster @ http://deb.debian.org/debian; echo $?for i in {dev,proc,sys}; do mount -o bind /$i @/$i; donecp /etc/bash.bashrc @/etc/chroot /mnt/@ /bin/bashecho rbd1 > /etc/hostnamepasswduuid=`blkid | grep $blkdev | cut -d "\"" -f 2`cat << EOF > /etc/fstabUUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2EOFcat << EOF >> /var/lib/dpkg/statusPackage: lvm2Status: install ok installedPriority: importantSection: adminInstalled-Size: 0Maintainer: Debian Adduser Developers <adduser@packages.debian.org>Architecture: allMulti-Arch: foreignVersion: 113.118Description: No-installPackage: sudoStatus: install ok installedPriority: importantSection: adminInstalled-Size: 0Maintainer: Debian Adduser Developers <adduser@packages.debian.org>Architecture: allMulti-Arch: foreignVersion: 113.118Description: No-installEOFexitgrub-install --boot-directory=@/boot/ /dev/$blkdevinit 6apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh  smartmontools ntfs-3g net-tools manexitgrub-install --boot-directory=@/boot/ /dev/$blkdevinit 6


Создание кластера
apt -yq install --no-install-recommends gnupg wget ca-certificatesecho 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.listwget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -apt updateapt -yq install --no-install-recommends ceph-common ceph-monecho 192.168.11.11 rbd1 >> /etc/hostsuuid=`cat /proc/sys/kernel/random/uuid`cat << EOF > /etc/ceph/ceph.conf[global]fsid = $uuidauth cluster required = cephxauth service required = cephxauth client required = cephxmon allow pool delete = truemon host = 192.168.11.11mon initial members = rbd1mon max pg per osd = 385osd crush update on start = false#osd memory target = 2147483648osd memory target = 1610612736osd scrub chunk min = 1osd scrub chunk max = 2osd scrub sleep = .2osd pool default pg autoscale mode = offosd pool default size = 1osd pool default min size = 1osd pool default pg num = 1osd pool default pgp num = 1[mon]mgr initial modules = dashboardEOFceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'cp ceph.client.admin.keyring /etc/ceph/ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyringceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyringceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyringmonmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmaprm -R /var/lib/ceph/mon/ceph-rbd1/*ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyringchown ceph:ceph -R /var/lib/cephsystemctl enable ceph-mon@rbd1systemctl start ceph-mon@rbd1ceph mon enable-msgr2ceph status# dashboardapt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yamlmkdir /var/lib/ceph/mgr/ceph-rbd1ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyringsystemctl enable ceph-mgr@rbd1systemctl start ceph-mgr@rbd1ceph config set mgr mgr/dashboard/ssl falseceph config set mgr mgr/dashboard/server_port 7000ceph dashboard ac-user-create root 1111115 administratorsystemctl stop ceph-mgr@rbd1systemctl start ceph-mgr@rbd1


Добавление OSD (часть)
apt install ceph-osdosdnum=`ceph osd create`mkdir -p /var/lib/ceph/osd/ceph-$osdnummkfs -t xfs /dev/sda1mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnumcd /var/lib/ceph/osd/ceph-$osdnumceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyringln -s /dev/disk/by-partuuid/d8cc3da6-02  blockceph-osd -i $osdnum --mkfs#chown ceph:ceph /dev/sd?2chown ceph:ceph -R /var/lib/cephsystemctl enable ceph-osd@$osdnumsystemctl start ceph-osd@$osdnum


Резюме


Главное маркетинговое преимущество CEPH это CRUSH алгоритм вычисления расположения данных. Мониторы распространяют клиентам этот алгоритм, после чего клиенты напрямую запрашивают нужный узел и нужный OSD. CRUSH обеспечивает отсутствие централизации. Он представляет собой маленький файл, который можно хоть распечатать и повесить на стену. Практика показала, что CRUSH не является исчерпывающей картой. Если уничтожить и заново создать мониторы, сохранив все OSD и CRUSH, то этого недостаточно для восстановления кластера. Отсюда сделан вывод, что на каждом мониторе хранятся некоторые метаданные обо всём кластере. Незначительный объём этих метаданных не накладывает ограничений на размер кластера, но требует обеспечить их сохранность, что исключает экономию диска за счёт установки системы на флешку и исключает кластеры с менее, чем тремя узлами. Агрессивная политика разработчика в отношении опциональных фич. Далеко до минимализма. Документация на уровне: за то, что есть, уже спасибо, но очень, очень скудно. Возможность взаимодействия со службами на низком уровне предусмотрена, но документация слишком поверхностно касается этой темы, поэтому скорее нет, чем да. Практически никакие шансы на восстановление данных из внештатной ситуации.

Варианты дальнейших действий: отказаться от CEPH и воспользоваться банальным много-дисковым btrfs (или xfs, xfs), узнать новую информацию о CEPH, которая позволит эксплуатировать его в указанных условиях, попробовать в качестве повышения квалификации написать собственное хранилище.
Подробнее..

Токенизация карт в E-commerce что это такое и как работает?

03.07.2020 12:17:33 | Автор: admin

Всем привет! Недавно мы в Яндекс.Кассе совместно с платежными системами Visa и Mastercard запустили новую технологию токенизации платежей для E-commerce, или, по-другому, онлайн-коммерции. Кто-то может подумать: что тут такого с токенизацией карт разобрались уже с выходом Apple Pay, Google Pay и других *Pay. Но нет, тут что-то новенькое, а мы еще и первыми эту технологию запустили в России этой весной для магазинов-партнеров, так что почему бы не поделиться.


В США и Европе эта технология появилась несколько раньше, и пользователи таких сервисов, как Netflix и Amazon, уже платят E-commerce токенами, хотя, возможно, даже не знают об этом. А я сейчас расскажу, как это устроено не только снаружи (для партнеров и держателей карт), но и изнутри, с точки зрения разработчика и тимлида этого проекта. Если интересно велкам под кат.



Что общего с Apple Pay и Google Pay

Те читатели, которые представляют, как работают Apple Pay и Google Pay (а кто не знает вот наша статья про запуск *Pay), увидят тут знакомые слова.

Если коротко, то одна из особенностей технологий *Pay заключается в том, что плательщику не нужно передавать магазину данные своей банковской карты. Он один раз обменивает их на специальный цифровой токен и дальше, не подвергаясь риску перехвата данных карты, при платеже использует только этот токен. А преимущество в том, что токен работает только вместе с одноразовой криптограммой, которая генерируется на телефоне плательщика, а вне телефона эту криптограмму создать не получится. К тому же этими токенами легко управлять удалять или создавать новые дело одной минуты в онлайне, никаких походов в банк и прочей бюрократии.

Пока запомним эти особенности токенизации карт на устройствах пользователей:

  • платить токеном может только тот, кто этот токен создал,
  • управлять токеном можно отдельно и независимо от управления банковской картой.

Запомнили? А теперь перейдем к токенизации карт для E-commerce, иначе говоря, для онлайн-платежей в интернет-магазинах.

Итак, что такое токенизация в E-commerce

Вообще, токенизация карты это обмен конфиденциальных данных банковской карты на специальный токен, который позволяет оплачивать покупки с помощью этой карты.
Конфиденциальные данные карты это ее номер (PAN Primary Account Number) и срок действия.

Если для подключения карты в *Pay инициатором является сам держатель карты, то токенизацию для E-commerce инициирует интернет-магазин. Но зачем (и с какой стати)?

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

Нужно понимать, что такое действие подразумевает, что магазин должен где-то сохранить данные карты. Тут обычно два варианта:

  1. сохранить их на собственных серверах, если они сертифицированы на соответствие стандарту PCI DSS, что могут себе позволить далеко не все интернет-магазины,
  2. доверить их хранение своему платежному решению, например Яндекс.Кассе, которая сертифицирована PCI DSS по высшему уровню безопасности.

А нельзя ли и здесь применить подход с токенизацией? Почему бы вместо хранения данных банковской карты не использовать некоторый токен, которым можно управлять отдельно от карты? А что если сделать так, чтобы при очередном перевыпуске карты токен оставался бы одним и тем же и не нужно было заново привязывать карту к разным сервисам? Звучит любопытно?

Давайте обо всем по порядку. При токенизации мы обмениваем данные банковской карты на некий токен, но что это такое? Токен предоставляется платежной системой карты Mastercard или Visa. Он представляет собой уникальный идентификатор, аналогичный номеру учетной записи устройства в Apple Pay или номеру виртуального счета в Google Pay, которые можно найти в приложении на смартфоне (Wallet на устройствах Apple и Google Pay на Android).

В отличие от *Pay, в E-commerce токенизации создание токена инициирует интернет-магазин или его платежное решение, а сами токены хранятся на серверах платежных систем.

Разумеется, кто угодно не может прийти к платежной системе и получить токен чьей-либо карты для оплаты покупок. Во-первых, токенизировать карты могут только те платежные решения, которые пройдут сертификацию и получат одобрение платежных систем. Такое платежное решение называется On-Behalf Token Requestor или Token Service Provider, но для простоты будем впредь оперировать термином Token Requestor. И только Token Requestor может инициировать платежи токеном. Во-вторых, токен всегда выпускается для конкретного магазина, и с помощью токена можно платить только в этом магазине. Очень похоже на то, как токен *Pay связан с устройством, на котором он был создан.

За счет чего это достигается? Просто перед проведением каждого платежа по токену Token Requestor должен получить одобрение у платежной системы на этот платеж. Факт такого одобрения надо будет предъявить во время фактического проведения платежа, поэтому одобрение это имеет форму одноразовой криптограммы, которую формирует платежная система карты. При проведении платежа эта криптограмма добавляется к параметрам запроса в банк-эквайер и затем передается платежной системе, которая проверяет подлинность этой криптограммы, которую сама ранее выдавала.

А что там про управление токеном независимо от управления картой? Тут вообще все просто токен живет своей жизнью, имеет свои статусы жизненного цикла, и о каждом изменении статуса Token Requestor сразу же узнает от платежной системы карты.

Подведем некоторый итог. Что токенизация дает держателю карты?

  1. Сохранность данных реальной банковской карты. При платеже используется токен, а сами данные карты не передаются, поэтому их никак не сможет перехватить потенциальный злоумышленник. А перехватывать данные токена нет никакого смысла, потому что токен превращается в тыкву при попытке заплатить в любом другом магазине.
  2. При перевыпуске банковской карты токен, выпущенный для интернет-магазина, продолжает действовать, и владельцу карты нет необходимости привязывать новую карту к нужным ему сервисам.
  3. Возможность управления токеном. Токенами можно будет управлять, не затрагивая саму банковскую карту. Банки-эмитенты смогут реализовать в своих интерфейсах специальные инструменты для гибкого управления привязками в интернет-магазинах (создание токена в новом магазине, просмотр имеющихся токенов, удаление неактуальных).

Что это дает интернет-магазинам?

  1. То, что хорошо для покупателя, хорошо и для магазина, поэтому использование токенизированных карт может повысить лояльность клиентов.
  2. Возможность перевыпуска банковской карты с сохранением токена важна для магазинов, использующих сценарии платежей по подписке. Магазину больше не нужно будет отключать подписку, если пользователь забыл обновить данные карты, и не придется всячески напоминать ему об этом. Стоит отметить, что у держателя карты все равно остается полный контроль и в любой момент он сможет отключить саму подписку.
  3. Повышение конверсии платежей. Мы исследовали, как использование токенов влияет на конверсию платежей в сравнении с использованием сохраненных данных карт. Выяснилось, что доля успешных платежей без использования токенов была 88,53%, а после включения токенизации выросла до 97,89%*. Получившаяся разница объясняется тем, что если банк-эмитент уже одобрил создание токена, то в дальнейшем платежи этим токеном будут вызывать большее доверие у антифрод-системы банка. На конверсию влияет также возможность оплаты перевыпущенными картами. Если человек не обновит данные карты, которую он привязал к интернет-магазину, то оплата не пройдет, а с токеном такой проблемы не возникнет.

*Мы сравнивали платежи за этот апрель в крупном онлайн-кинотеатре (MCC 4899) привязанными картами без 3DS, без учета неуспешных платежей из-за нехватки денег на карте.

Технические аспекты

Для любителей копнуть чуть глубже, расскажу о технологии токенизации карт и ее запуске в Яндекс.Кассе как все это выглядит изнутри нашего платежного решения.

Интеграция с платежными системами

Чтобы получить техническую возможность токенизировать карты и проводить платежи токенами, необходимо интегрироваться с Visa и Mastercard, пройти тесты, сертификацию и получить их одобрение на запуск в production. Поначалу это звучало устрашающе. Да и не только поначалу, если честно, по крайней мере, для меня. Но устрашала скорее сертификация, а по технике все было предельно ясно.

Интеграция подразумевает реализацию следующего API (условно) между платежной системой и нами в качестве Token Requestor:

  1. Создание токена.
    Мы передаем платежной системе данные банковской карты и идентификатор интернет-магазина, для которого создается токен. Дополнительно мы проводим скоринг для оценки рисков (risk scoring) токенизации конкретной карты для конкретного магазина и также передаем результат скоринга в запросе. В ответ мы получаем решение, одобрена токенизация карты ее эмитентом или нет, и если одобрена, получаем уникальный идентификатор созданного токена. После этого токен активен, можно проводить платежи с его использованием.
  2. Получение одноразовой криптограммы для платежа токеном.
    Мало обладать токеном, чтобы им платить: для каждого платежа нужно еще получить одобрение от платежной системы криптограмма, помните? Так вот, чтобы получить эту криптограмму, мы передаем в запросе платежной системе идентификатор токена и некоторые детали платежа. Если токен активен, мы в ответе получаем эту одноразовую криптограмму, которую затем надо будет передать эквайеру при проведении платежа по карте.
  3. Уведомление от платежной системы об изменении состояния токена.
    Это может быть приостановка/возобновление действия токена по инициативе держателя карты, удаление этого токена навсегда, а также обновление данных банковской карты, для которой был выпущен этот токен, в случае ее перевыпуска. Нам нужно уметь обрабатывать определенные запросы от платежных систем и обновлять у себя информацию о токене, проще простого.

Это описание API условное и обобщенное нетрудно догадаться, что у каждой платежной системы разные форматы запросов/ответов, алгоритмы подписи и шифрования данных в запросах, и есть различные нюансы в бизнес-логике. Поэтому все эти детали и различия мы скрыли от остальной нашей системы, создав отдельный сервис токенизации карт, который является адаптером к платежным системам и полностью отвечает за жизненный цикл токенов.

Токенизация в Яндекс.Кассе

Яндекс.Касса представляет из себя большую систему по приему платежей для интернет-магазинов. Она состоит из многих десятков различных сервисов: backend-, frontend-приложения, BI-сервисы. Они обеспечивают прием платежа пользователя различными способами, перевод денежных средств магазину, управление платежами через личный кабинет магазина, аналитические сервисы и тому подобное. И как именно сюда встроилась токенизация карт?

Главный вопрос: в какой момент создавать токен для банковской карты?
В API Яндекс.Кассы есть возможность сохранять выбранный способ оплаты для последующих платежей в будущем, мы это называем автоплатежи.

Это может происходить как при привязке карты к аккаунту пользователя в личном кабинете магазина, так и при подписке на периодической основе, когда платежи с карты будут проводиться автоматически. В обоих сценариях при создании платежа магазин по API передает параметр save_payment_method: true, и после успешного платежа мы выдаем магазину payment_method_id идентификатор сохраненного способа оплаты, с помощью которого он сможет проводить новые платежи.

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

Что же сами платежные системы делают в момент токенизации карты?
Они обращаются в банк-эмитент, с запросом на создание токена (как это происходит и при создании токенов *Pay), и банк выпускает токен для данного магазина. Банк также может уведомить об этом держателя карты и отобразить созданный токен в его личном кабинете.

Как происходит платеж токеном?

Пожалуй, тут понадобится некоторая иллюстрация, как вообще проходит платеж ранее сохраненной картой, который инициирует интернет-магазин:



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

С токенами в этом сценарии добавляется еще один шаг:



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

А что происходит в сценарии, когда пользователь перевыпускает карту в своем банке?
Если к карте ранее были выпущены токены, то банк-эмитент сообщает в платежную систему Mastercard/Visa, что карта перевыпущена. В свою очередь, каждый Token Requestor, который выпускал токены к этой карте, получит уведомление от платежной системы. Оно содержит обновленную информацию о карте: последние 4 цифры номера и новый срок действия. Токен при этом остается прежним.

Когда магазин инициирует очередной платеж с уже просроченной карты, которая на самом деле была перевыпущена, а у нас есть токен к ней для этого магазина платеж пройдет успешно. К тому же мы сообщим магазину уже новые последние 4 цифры банковской карты они будут присутствовать в ответах нашего API. Это нужно для того, чтобы и магазин, и пользователь всегда видели, с какой именно карты списываются средства.

Вместо заключения

Токенизация в E-commerce это новый этап развития приема платежей, повышающий удобство для всех участников процесса оплаты. Мы ожидаем, что в ближайшее время технологию поддержат многие российские банки и провайдеры и она станет новым стандартом платежного рынка.

Конечно, рассказ получился скорее обзорным, но я надеюсь, что каждый читатель найдет в нем что-то полезное для себя повысит свой уровень финансовой грамотности, узнает о новинках в финтехе или, может, найдет идею для развития своего бизнеса.

Я всё, будьте здоровы и не болейте!
Подробнее..

Системы изоляции воздушных коридоров ЦОД. Часть 2. Холодные и горячие коридоры. Какой изолируем?

03.07.2020 18:07:41 | Автор: admin

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


Изоляция холодного коридора


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



Установка стоек: для изоляции холодного коридора шкафные кондиционеры располагаются по периметру помещения и выдувают холодный поток воздуха под фальшпол. При этом монтажные шкафы стоят в ряд лицом друг к другу.
Плюсы:


  • относительно невысокая стоимость,
  • простота масштабирования: шкафной кондиционер можно установить в любое свободное место по периметру машзала.

Минусы:


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

Конструктивные особенности:


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

Кому подходит: небольшим серверным помещениям, либо машзалам с невысокой нагрузкой (до 5 кВт на стойку).


Горячий коридор


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



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


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

Минусы:


  • цена: в данном варианте нужно больше кондиционеров, при этом для каждого контейнера необходим свой резервный кондиционер,
  • межрядные кондиционеры занимают место, которое можно было бы использоваться под серверные шкафы,
  • сложности масштабирования: добавление кондиционеров возможно, только если заранее предусмотрены дополнительные точки подключения
.
Конструктивные особенности:
  • помещение не требует дополнительного запаса по высоте,
  • сам контейнер изолируется по внешнему периметру коридора,
  • в шкафах необходимы изоляция переднего фронта и заглушка-цоколь, а также изоляция всех крыш шкафов,
  • для торцевых шкафов коридора нужна изоляция боковых сторон шкафа и цоколя по внешнему периметру.


Кому подходит: небольшим и средним серверных помещений с высокой нагрузкой (до 10 кВт на стойку).

Частный случай: системы контейнеризации шкафов с закрытым контуром охлаждения.


Принцип действия: кондиционеры устанавливаются рядом со шкафами или внутри них, образуя единые закрытые горячие и холодные зоны. Воздухообмен при этом происходит внутри шкафа (или небольшой группы шкафов).
Плюсы:
  • высокопроизводительное решение, которое применяется с нагруженными стойками или в помещении, не предназначенном для размещения ИТ-оборудования (контейнер выполняет также функцию защитной оболочки для ИТ оборудования),
  • может использоваться в помещениях с низким потолком.

Минусы:
  • высокая стоимость решения исключает возможность массового размещения шкафов,
  • ограниченная возможность масштабирования: для обеспечения резервирования для каждого комплекта требуется отдельный кондиционер,
  • усложнение системы пожаротушения: каждый закрытый шкаф превращается в отдельный отсек, нуждающийся в своем наборе датчиков мониторинга и в локальной системе для пожаротушения.

Конструктивные особенности:
помещение не требует дополнительного запаса по высоте,
конструктив шкафа предусматривает полностью закрытый контур, в том числе, с возможностью защиты по IP.

Кому подходит: тем, кому необходимо размещение высоконагруженных вычислительных комплексов (до 20 кВт на стойку).

Подробнее..

Recovery mode От стартапа до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры

03.07.2020 20:16:17 | Автор: admin
Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.



Разумеется, НСПК не стартап, но такая атмосфера царила в компании в первые годы существования, и это были очень интересные годы. Меня зовут Корняков Дмитрий, более 10 лет я поддерживаю инфраструктуру Linux с высокими требованиями доступности. К команде НСПК присоединился в январе 2016 года и, к сожалению, не застал самого начала существования компании, но пришел на этапе больших изменений.

В целом, можно сказать, что наша команда поставляет для компании 2 продукта. Первый это инфраструктура. Почта должна ходить, DNS работать, а контроллеры домена пускать вас на сервера, которые не должны падать. IT ландшафт компании огромен! Это business&mission critical системы, требования по доступности некоторых 99,999. Второй продукт сами сервера, физические и виртуальные. За существующими нужно следить, а новые регулярно поставлять заказчикам из множества подразделений. В этой статье я хочу сделать акцент на том, как мы развивали инфраструктуру, которая отвечает за жизненный цикл серверов.

Начало пути

В начале пути наш стек технологий выглядел так:
ОС CentOS 7
Контроллеры домена FreeIPA
Автоматизация Ansible(+Tower), Cobbler


Всё это располагалось в 3х доменах, размазанных на нескольких ЦОДах. В одном ЦОД офисные системы и тестовые полигоны, в остальных ПРОД.

Создание серверов в какой-то момент выглядело так:



В шаблоне VM CentOS minimal и необходимый минимум вроде корректного /etc/resolv.conf, остальное приезжает через Ansible.

CMDB Excel.

Если сервер физический, то вместо копирования виртуальной машины на него устанавливалась ОС с помощью Cobbler в конфиг Cobbler добавляются MAC адреса целевого сервера, сервер по DHCP получает IP адрес, а дальше наливается ОС.

Поначалу мы даже пытались делать какой-то configuration management в Cobbler. Но со временем это стало приносить проблемы с переносимостью конфигураций как в другие ЦОД, так и в Ansible код для подготовки VM.

Ansible в то время многие из нас воспринимали как удобное расширение Bash и не скупились на конструкции с использованием shell, sed. В общем Bashsible. Это в итоге приводило к тому, что, если плейбук по какой-либо причине не отрабатывал на сервере, проще было удалить сервер, поправить плейбук и прокатить заново. Никакого версионирования скриптов по сути не было, переносимости конфигураций тоже.

Например, мы захотели изменить какой-то конфиг на всех серверах:

  1. Изменяем конфигурацию на существующих серверах в логическом сегменте/ЦОД. Иногда не за один день требования к доступности и закон больших чисел не позволяет применять все изменения разом. А некоторые изменения потенциально деструктивны и требуют перезапуск чего-либо от служб до самой ОС.
  2. Исправляем в Ansible
  3. Исправляем в Cobbler
  4. Повторяем N раз для каждого логического сегмента/ЦОД

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

  • Рефакторинг ansible кода, конфигурационных файлов
  • Изменение внутренних best practice
  • Изменения по итогам разбора инцидентов/аварий
  • Изменение стандартов безопасности, как внутренних, так и внешних. Например, PCI DSS каждый год дополняется новыми требованиями

Рост инфраструктуры и начало пути

Количество серверов/логических доменов/ЦОД росло, а с ними количество ошибок в конфигурациях. В какой-то момент мы пришли к трём направлениям, в сторону которых нужно развивать configuration management:

  1. Автоматизация. Насколько возможно, нужно избегать человеческого фактора в повторяющихся операциях.
  2. Повторяемость. Управлять инфраструктурой намного проще, когда она предсказуема. Конфигурация серверов и инструментов для их подготовки должна быть везде одинаковой. Это так же важно для продуктовых команд приложение должно гарантированно после тестирования попадать в продуктивную среду, настроенную аналогично тестовой.
  3. Простота и прозрачность внесения изменений в configuration management.

Осталось добавить пару инструментов.

В качестве хранилища кода мы выбрали GitLab CE, не в последнюю очередь за наличие встроенных модулей CI/CD.

Хранилище секретов Hashicorp Vault, в т.ч. за прекрасное API.

Тестирование конфигураций и ansible ролей Molecule+Testinfra. Тесты идут намного быстрее, если подключаете к ansible mitogen. Параллельно мы начали писать собственную CMDB и оркестратор для автоматического деплоя (на картинке над Cobbler), но это уже совсем другая история, о которой в будущем расскажет мой коллега и главный разработчик этих систем.

Наш выбор:

Molecule + Testinfra
Ansible + Tower + AWX
Мир Серверов + DITNET(Собственная разработка)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault




Кстати про ansible роли. Сначала она была одна, после нескольких рефакторингов их стало 17. Категорически рекомендую разбивать монолит на идемпотентные роли, которые можно потом запускать отдельно, дополнительно можно добавить теги. Мы роли разбили по функционалу network, logging, packages, hardware, molecule etc. А вообще, придерживались стратегии ниже. Не настаиваю на том, что это истина в единственной инстанции, но у нас сработало.

  • Копирование серверов из золотого образа зло!

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

    1. Оставьте /etc/sysctl.conf пустым, настройки должны лежать только в /etc/sysctl.d/. Ваш дефолт в один файл, кастом для приложения в другой.
    2. Используйте override файлы для редактирования systemd юнитов.
  • Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
  • Рефактория код системы управления конфигурациями:

    1. Разбейте задачи на логические сущности и перепишите монолит на роли
    2. Используйте линтеры! Ansible-lint, yaml-lint, etc
    3. Меняйте подход! Никакого bashsible. Нужно описывать состояние системы
  • Под все Ansible роли нужно написать тесты в molecule и раз в день генерировать отчёты.
  • В нашем случае, после подготовки тестов (которых больше 100) нашлось около 70000 ошибок. Исправляли несколько месяцев.


Наша реализация

Итак, ansible роли были готовы, шаблонизированы и проверены линтерами. И даже гиты везде подняты. Но вопрос надежной доставки кода в разные сегменты остался открытым. Решили синхронизировать скриптами. Выглядит так:



После того, как приехало изменение, запускается CI, создаётся тестовый сервер, прокатываются роли, тестируются молекулой. Если всё ок, код уходит в прод ветку. Но мы не применяем новый код на существующие сервера в автомате. Это своеобразный стопор, который необходим для высокой доступности наших систем. А когда инфраструктура становится огромной, в дело идёт ещё закон больших чисел даже если вы уверены, что изменение безобидное, оно может привести к печальным последствиям.

Вариантов создания серверов тоже много. Мы в итоге выбрали кастомные скрипты на питоне. А для CI ansible:

- name: create1.yml - Create a VM from a template  vmware_guest:    hostname: "{{datacenter}}".domain.ru    username: "{{ username_vc }}"    password: "{{ password_vc }}"    validate_certs: no    cluster: "{{cluster}}"    datacenter: "{{datacenter}}"    name: "{{ name }}"    state: poweredon    folder: "/{{folder}}"    template: "{{template}}"    customization:      hostname: "{{ name }}"      domain: domain.ru      dns_servers:        - "{{ ipa1_dns }}"        - "{{ ipa2_dns }}"    networks:      - name: "{{ network }}"        type: static        ip: "{{ip}}"        netmask: "{{netmask}}"        gateway: "{{gateway}}"        wake_on_lan: True        start_connected: True        allow_guest_control: True    wait_for_ip_address: yes    disk:      - size_gb: 1        type: thin        datastore: "{{datastore}}"      - size_gb: 20        type: thin        datastore: "{{datastore}}"

Вот к чему мы пришли, система продолжает жить и развиваться.

  • 17 ansible-ролей для настройки сервера. Каждая из ролей предназначена для решения отдельной логической задачи (логирование, аудит, авторизация пользователей, мониторинг и т.д.).
  • Тестирование ролей. Molecule + TestInfra.
  • Собственная разработка: CMDB + Оркестратор.
  • Время создания сервера ~30 минут, автоматизировано и практически не зависит от очереди задач.
  • Одинаковое состояние/именование инфраструктуры во всех сегментах плейбуки, репозитории, элементы виртуализации.
  • Ежедневная проверка состояния серверов с генерацией отчётов о расхождениях с эталоном.

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

Наши уникальные бесплатные мастер-курсы Kubernetes, CLI tool для разработчиков Odo, Java в контейнерах и много книг

04.07.2020 00:19:48 | Автор: admin
Окей, мы инновационная ИТ-компания, а значит у нас есть разработчики и это хорошие разработчики, увлеченные своим делом.



А еще они проводят live streaming, и все вместе это называется DevNation.

Начни новое:



Строй:



Немного от HR:


  • Как просить повышения во время COVID-19
    Несмотря на то, что пандемия заставляет многие компании сокращать свои бюджеты, технические навыки необходимы как никогда. Используйте эти советы, чтобы доказать свою ценность и получить повышение заработной платы в неспокойное время.
  • 3 совета, чтобы избежать выгорания во время работы из дома
    Статья в Harvard Business Review с тремя надежными пунктами по борьбе с выгоранием, а еще советы для работодателей, менеджеров и коллег, которые хотят помочь.

Пообщаться:


Ежемесячные вебинары для разработчиков от бабушкиМаркуса, главы Developer Adoption Program. Маркус приглашает друзей для обмена опытом в проектировании и создании современных приложений.



Список ближайших тем:

  • Quarkus the black swan of Java
  • Helm for Developers
  • Supersonic Secure Java with Quarkus
  • Stream Processing with Quarkus, Kafka Streams and Knative
  • Securing Microservices
  • DevOps with Containers
  • Orchestrating microservices the cloud-native way

По-русски:


Подробнее..

Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать. Алексей Зателепин (2018г)

04.07.2020 16:09:21 | Автор: admin

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


Будут затронуты следующие темы:


  • Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
  • Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
  • Как диагностировать проблемы на production-кластере ClickHouse.


Видео:



Идея доклада довольно проста: что если каким-то инструментом пользуешься или собираешься пользоваться, то желательно хотя бы в общих чертах представлять, что там внутри происходит, чтобы каких-то неправильных решений избежать и принять правильное решение. Вот такое понимание про ClickHouse постараюсь сегодня донести.



Я ClickHouse занимаюсь недавно. До этого я несколько лет работал в Яндекс.Картах. Был прикладным разработчиком. Много там работал с базами данных, с Postgres, поэтому я еще вирусом ClickHouse не сильно заражен, я еще помню, что такое быть прикладным разработчиком. Но, в принципе, уже все довольно хорошо понимаю.



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


У нас есть некие события. Они постоянно приходят. Я тут выписал какие-то примеры. Вот Яндекс.Метрика это сервис, для которого ClickHouse изначально создавался.


  • Это какие-то действия пользователя на сайте.
  • Реклама.
  • Финансовые транзакции, покупки в магазинах.
  • И DNS-запросы.

Что мы хотим с этими событиями сделать? Мы хотим о них сохранить информацию и что-то о них понять потом, т. е. построить какие-то отчеты, аналитику, потом на них посмотреть и что-то понять.



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


Для ClickHouse самое важное:


  • Это интерактивные запросы. Что это такое? Это выполнение за секунды, а лучше меньше, чем за секунду. Почему это важно? Во-первых, когда Яндекс.Метрика показывает отчет, пользователь не будет ждать, если он загружается больше секунды. Но даже если вы, как аналитик, работаете с ClickHouse, с базой данной, то очень хорошо, если ответы на запросы тут же приходят. Вы тогда их можете много задать. Вы можете не отвлекаться. Вы можете погрузиться в работу с данными. Это другое качество работы.
  • Язык запросов у нас SQL. Это тоже и плюсы, и минусы. Плюсы в том, что SQL декларативный и поэтому простой запрос можно очень хорошо оптимизировать, т. е. очень оптимально выполнить. Но SQL не очень гибкий. Т. е. произвольную трансформацию данных с помощью SQL не задать, поэтому там у нас куча каких-то расширений, очень много функций дополнительных. А преимущество в том, что SQL все аналитики знают, это очень популярный язык.
  • Стараемся ничего заранее не агрегировать. Т. е. когда такую систему делаешь, то очень велик соблазн сначала подумать о том, какие отчеты нужны. Подумать, что у меня события будут поступать, я их буду потихоньку агрегировать и нужно будет показать отчет, я быстренько вот это все покажу. Но есть проблема такого подхода. Если вы два события слили вместе, то вы уже их ни в каком отчете больше не различите. Они у вас вместе. Поэтому чтобы сохранить гибкость, стараемся всегда хранить индивидуальные события и заранее ничего не агрегировать.
  • Еще один важный пункт, который требуется от прикладного разработчика, который работает с ClickHouse. Нужно заранее понять, какие есть атрибуты события. Нужно их самому выделить, вычленить и уже эти атрибуты запихивать в ClickHouse, т. е. какие-то json в свободной форме или текстовые blob, которые вы просто берете и пихаете, и надеетесь потом распарсить. Так лучше не делать, иначе у вас интерактивных запросов не будет.


Возьмем пример достаточно простой. Представим, что мы делаем клон Яндекс.Метрики, систему веб-аналитики. У нас есть счетчик, который мы на сайт ставим. Он идентифицируется колонкой CounterID. У нас есть таблица hits, в которую мы складываем просмотры страниц. И есть еще колонка Referer, и еще что-то. Т. е. куча всего, там 100 атрибутов.


Очень простой запрос делаем. Берем и группируем по Referer, считаем count, сортируем по count. И первые 10 результатов показываем.



Запрос нужно выполнить быстро. Как это сделать?


Во-первых, нужно очень быстро прочитать:


  • Самое простое, что тут надо сделать, это столбцовая организация. Т. е. храним данные по столбцам. Это нам позволит загрузить только нужные столбцы. В этом запросе это: ConterID, Date, Referrer. Как я уже сказал, их может быть 100. Естественно, если мы их все будем загружать, это все очень сильно нас затормозит.
  • Поскольку данные у нас в память, наверное, не помещаются, нам нужно читать локально. Конечно, мы не хотим читать всю таблицу, поэтому нам нужен индекс. Но даже если мы читаем эту маленькую часть, которая нам нужна, нам нужно локальное чтение. Мы не можем по диску прыгать и искать данные, которые нам нужны для выполнения запроса.
  • И обязательно нужно данные сжимать. Они в несколько раз сжимаются и пропускную способность диска очень сильно экономят.


И после того, как мы данные прочитали, нам нужно их очень быстро обработать. В ClickHouse много чего для этого делается:


  • Самое главное, что он их обрабатывает блоками. Что такое блок? Блок это небольшая часть таблицы, размером где-то в несколько тысяч строк. Почему это важно? Потому что ClickHouse это интерпретатор. Все знают, что интерпретаторы это очень медленно. Но если мы overhead размажем на несколько тысяч строк, то он будет незаметен. Зато это нам позволит применить SIMD инструкции. И для кэша процессора это очень хорошо, потому что если мы блок подняли в кэш, там его обрабатываем, то это будет гораздо быстрее, чем если он куда-то в память будет проваливаться.
  • И очень много низкоуровневых оптимизаций. Я про это не буду говорить.


Так же, как и в обычных классических БД мы выбираем, смотрим, какие условия будут в большинстве запросов. В нашей системе веб-аналитике, скорее всего, это будет счетчик. Хозяин счетчика будет приходить и смотреть отчеты. А также дата, т. е. он будет смотреть отчеты за какой-то период времени. Или, может быть, он за все время существования захочет посмотреть, поэтому такой индекс CounterID, Date.


Как мы можем проверить, что он подойдет? Сортируем таблицу по CounterID, Date и смотрим наши строки, которые нам нужны, они занимают вот такую небольшую область. Это значит, что индекс подойдет. Он будет сильно ускорять.


Но есть у ClickHouse индекса и особенности в отличие от привычных индексов. Во-первых, таблица будет упорядочена по ключу физически. В других системах еще называют кластер индекс. Это значит, что такой индекс на таблицу может быть только один. Второе, несмотря на то, что мы его называем первичный ключ, он не обеспечивает уникальности. Об этом нужно помнить.



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


И когда у нас этот индекс есть, то при выполнении запроса, что мы делаем? Мы должны выбрать строки, которые нам могут пригодиться для выполнения запроса. В данном случае нам нужен счетчик 1234 и дата с 31 мая. А тут только есть запись на 23 мая. Это значит, что мы, начиная с этой даты, все должны прочитать. И до записи, счетчик которой начинается уже 1235. Получается, что мы будем читать немножко больше записей, чем нужно. И для аналитических задач, когда вам много нужно строк прочитать это не страшно. Но если вам нужна какая-то одна строка, то работать все будет не так хорошо. Чтобы найти одну строку, вам придется 8 000 прочитать.


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


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


Что тут важно? Key-Value сценарий будет плохо работать. У меня здесь светло-серым обозначено то, что мы прочитаем, и темно-серым то, что нам. И вполне может быть, что вам нужна будет одна строка, а вы прочитаете много.


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



Я сказал, что таблица упорядочена, но не рассказал, как это сделать. А нам очень хочется, чтобы данные, которые поступают в ClickHouse, тут же были доступны для отчетов. Т. е. после insert секунда прошла, и вы уже их видите в своих отчетах.


И тут есть проблема, потому что данные поступают примерно по времени, т. е. события за последние какие-то несколько минут. А нам нужно по первичному ключу, т. е. по счетчику. А события как раз поступают по счетчикам перемешано. И нужно как-то их упорядочивать.


Как это сделать? В ClickHouse прилагается вот такое решение. Движок таблицы MergeTree. Идея примерно такая же, как у LSM дерева. Т. е. у нас есть небольшое количество упорядоченных кусочков. Если их становится много, то мы берем несколько кусочков и из них делаем один. Таким образом поддерживаем каждый раз небольшое количество.



Вот примерно, как это происходит. У нас по Х это номер вставки, т. е., грубо говоря, это время, которое вы вставляете. По У первичный ключ. Поступили данные. Они обозначены зеленым цветом. Они не упорядоченные.



Что делает ClickHouse? Прежде всего он их сортирует и потом записывает на диск. Появляется новый кусок. Что тут важно? Данные из вашего insert сразу попадут на диск, т. е. буферизации какой-то не будет и поэтому индивидуальными записями будет очень плохо писать.


Есть средства, например, буфер-таблицы в ClickHouse, которые позволяют снизить эту проблему, но все равно нужно делать вставки большими кусками. Мы рекомендуем делать это раз в секунду и, как минимум, 1 000 записей, иначе очень много будет езды по диску, и все будет очень плохо работать.



У нас появился новый кусок. Появилось что-то еще потом. Нужно количество кусков уменьшить. Вот этот процесс происходит в фоне. Называется слияние или merge.


У ClickHouse есть одна особенность. Слияние происходит только с кусками, которые были вставлены подряд. В нашем случае был кусок, которые объединяет вставки от M до N. И маленький кусочек, который мы вставили на предыдущем слайде, который был вставлен под номером N+1.



Мы берем их и сливаем. И получаем новый кусок М до N+1. Он упорядоченный.


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


Как это будет выглядеть в случае с ClickHouse? Когда у вас будет на партицию (партиция это месяц) 200 кусков, то у вас внезапно затормозятся вставки. Таким образом ClickHouse попробует дать возможность слияниям догнать вставки. А если уже будет 300 кусков, то он вам просто запретит вставлять, потому что иначе данные будет очень тяжело прочитать из множества кусков. Поэтому, если будете использовать ClickHouse, то обязательно это мониторьте. Настройте в ClickHouse экспорт метрик в Graphite. Это очень просто делается. И следите за количеством кусков в партиции. Если количество большое, то вам нужно обязательно разобраться с этим. Может быть, что-то с диском или вы начали очень сильно вставлять. И это нужно чинить.



Все хорошо. У нас есть сервер ClickHouse, все работает. Но иногда его может не хватать.


  • Самое банальное, когда данные на один сервер не поместились. Но это не единственный случай.
  • Например, хочется еще ускориться, добавив железа.
  • Или кластер ClickHouse стал таким популярным, что очень много одновременных запросов, они начинают мешать друг другу. И нужно добавить еще железа.

Что предлагает ClickHouse? Предлагает шардировать данные и использовать дистрибутивы таблицы.



Что это такое? Шардирование это понятно. У вас есть какая-то таблица. И вы ставите несколько компьютеров, и на каждом компьютере часть этих данных. У меня на картинке они в таблице local_table.


Что такое distributed таблицы? Это такой view над локальными таблицами, т. е. сама она данные не хранит. Она выступает как прокси, который отправит запрос на локальные таблицы. Ее можно создавать где угодно, хоть на отдельном компьютере от этих шардов, но стандартный способ это создание на каждом шарде. Вы тогда приходите в любой шард и создаете запрос.


Что она делает? Вот пошел запрос в select from distributed_table. Она возьмет его и перепишет distributed_table на local_table. И дальше отправит на все шарды сразу же.



Шарды запрос обработают. Причем они его стараются обрабатывать до самого конца практически, чтобы поменьше данных по сети передавать. Т. е. если у нас есть какая-то агрегация, то эта агрегация будет частично проведена на шардах. Они отошлют частично агрегированный результат на distributed таблицы. Distributed эту таблицу сольет и отправит полный результат пользователю.



Вот такой забавный benchmark. Чуть больше миллиарда строк. Это данные о поездках нью-йоркского такси. Они в открытом доступе лежат. Можно самому попробовать.


Посчитаем любой запрос. Тут средняя цена в зависимости от количества пассажиров. Типичный аналитический запрос. На одном компьютере чуть больше секунды. Если мы три компьютера доставим, то в три раза быстрее будет. Если у вас есть 140 компьютеров, то можно эти данные разложить по 140 компьютерам и запрос будет вообще быстро выполняться, т. е. за несколько миллисекунд. Конечно, это уже не 140-кратное ускорение, потому что сетевые задержки уже там начинают играть роль, но все равно. Запрос можно ускорять до самого конца.



Как теперь раскладывать данные по шардам?


Самый простой вариант, который мы рекомендуем, это взять и вручную разложить по локальным таблицам, потому что distributed таблица, когда она делает запрос, она не задумывается о том, как данные пошардированы, она просто спрашивает у всех шардов одновременно. Главное, чтобы данные не были задублированы, иначе у вас какая-то ерунда начнется в результатах. А так вы можете, как вам удобно раскладывать все по шардам.


Но, в принципе, distributed таблица и сама умеет это делать, хотя есть несколько нюансов.


Во-первых, записи асинхронные, т. е. если вы вставили в distributed эту таблицу, она данные отложит куда-то во временную папочку.



И дальше будет пытаться вставлять. Для этого ей нужен ключ шардирования. Она его посчитает, разделит на три. Там можно создавать веса. Далее выберет шард и вставит туда.


Что тут важно? Ключ шардирования можно даже рандом взять. Это тоже будет работать. Единственное, если вы хотите делать сложные joins и хотите, чтобы у вас данные, которые для joins нужны, были на одном шарде, тогда вам нужно уже задумываться о ключе шардирования.



Есть у нас кластер ClickHouse. Он большой, быстро работает, но иногда ломается. Иногда диски сбоят, а данные не хочется терять. И иногда там просто какие-то сетевые проблемы, а отчет нужно показывать. И данные о событиях, которые поступают постоянно, их тоже нельзя терять. Т. е. доступность должна быть и на чтение, и на запись.


ClickHouse предлагает для решения этой проблемы асинхронную мастер-мастер репликацию, которая работает на уровне таблиц ReplicatedMergeTree. На сервере у вас могут быть и реплицированные таблицы, и не реплицированные.



Это полный хаос. У нас есть несколько реплик. И тут изображены те же самые куски, о которых я говорил в предыдущей части презентации. Т. е. тут понимание остается такое же. Это частично сортированные кусочки данных. И реплики стараются вот этот набор кусков у себя синхронизировать друг между другом.


При этом может происходить три типа событий:


  • INSERT вставка в реплику
  • FETCH одна реплика скачала кусок с другой
  • MERGE реплика взяла несколько кусков и слила их в один

Как происходит вставка? Вставляем на любую реплику. Тут видно, что Реплика 1 не самая хорошая, но на нее все равно можно вставить. И информация о вставке записывается в ZooKeeper. Т. е. для того, чтобы у вас репликация работала, придется установить ZooKeeper.


При этом полный порядок на вставках все-таки поддерживается. У вас все реплики видят один и тот же набор кусков, и они видят в нем какие-то дырки, которых у них нет, и они пытаются их заполнить с помощью fetch.


Дальше нам нужно еще выполнять merge, т. е. сливать куски. Merge нужно выполнять согласовано, иначе наборы кусков разойдутся. Для этого одна реплика становится лидером. Не назовем мастером, потому что с мастером сразу идет ассоциация, что только туда можно вставлять, но это неправда. Т. е. у нас Реплика 2 лидер. Она решила, что эти куски надо помержить, записала это в ZooKeeper, остальные реплики об этом информацию получат и тоже сделают такой же merge.


При этом реплики все время сравнивают друг с другом checksums. Если что-то не так, они выбросят кусок и заново скачают, т. е. пытаются поддержать набор данных байт-идентичным. Это место тоже нужно обязательно мониторить, т. е. мониторить, как у вас идет репликация, какое отставание, чтобы не дай бог не сломалось.



И любое обсуждение репликации упирается в CAP-теорему, т. е. у вас есть какое-то место, где вы можете читать и писать, и вы его реплицируете, то в случае сетевого сбоя вам нужно сделать выбор: либо вы продолжаете читать и писать, либо вам все-таки нужны свежие данные правильные.


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


Доступность почти есть. Как сделать неубиваемый кластер ClickHouse? Берете три дата-центра. ZK в 3-х дата-центрах, а реплики, как минимум, в 2-х. И если у вас локация взрывается, то все продолжает работать и на чтение, и на запись.


Часто спрашивают: А как в двух дата-центрах сделать?. В двух не получится из-за ZooKeeper. Если у вас только две локации, то вы какой-то дата-центр объявляете главным. И если не главный отключается, то у вас все продолжает работать. Если главный отключаете, то у вас только на чтение.


Почему доступность почти? Почему красная звездочка? Строго говоря полной доступности нет, потому что нельзя записывать в сервер, если он у вас от quorum ZK, т. е. если это три ноды от двух нод отключены, тогда вы не сможете в него записать, но можете прочитать. Будут немножко отстающие данные.



Вот эти две фичи: distributed_table, replicated_table независимы. Их можно независимо использовать. Но они очень хорошо работают вместе. Нормальный кластер ClickHouse мы его примерно так себе представляем. Т. е. у нас есть N шардов и каждый трехкратно реплицирован. И distributed таблица умеет понимает, что шарды это реплики, могут отправлять запрос только в одну реплику шарда. И имеет отказоустойчивость, т. е. если у вас какая-то реплика недоступна, она в другую пойдет.


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



Что такое ClickHouse?


  • Это столбцовая column-oriented база данных, которая позволяет очень быстро выполнять аналитические и интерактивные запросы.
  • Язык запросов это SQL с расширениями.
  • Плохо подходит для OLTP, потому что транзакций нет. Key-Value, потому что у нас разреженный индекс. Если вам нужна одна строчка, то вы много чего лишнего прочитаете. И если у вас Key-Value с большими blob, то это вообще будет плохо работать.
  • Линейно масштабируется, если шардировать и использовать distributed таблицы.
  • Отказоустойчивая, если использовать replicate таблицы.
  • И все это в open source с очень активным community.


Вопросы


Здравствуйте! Меня зовут Дмитрий. Спасибо за доклад! Есть вопрос про дублирование данных. Я так понимаю, что в ClickHouse нет никакого способа решать эту проблему. Ее надо решать на этапе вставки или все-таки есть какие-то методы, которыми мы можем побороться с дублированием данных у нас в базе?


Откуда может возникнуть дублирование данных? Если у вас вставляльщик, который вставляет данные, отказоустойчивый, то он там делает retry. И когда он начинает делать retry, то, например, бац и ClickHouse отключился, а он продолжает делать retry. И в этот момент, конечно, может возникнуть дублирование данных. Но в ClickHouse оно не возникнет. Как мы от этого защищаемся?



Вот эта вставка блоками. В ZK хранятся checksums последних ста блоков. Это тоже настраиваемо, но 100 неплохой вариант. Поэтому если вы вставили блок и у вас что-то взорвалось, и вы не уверены вставили вы или нет, то вставьте еще раз. Если вставка прошла, то ClickHouse это обнаружит и не будет дублировать данные.


Т. е. если мы вставляем по 10 000 строк, у нас там будет храниться миллион строк, которые будут гарантировано недублированными?


Нет. Дублирование работает не на уровне строк.


Т. е. кусок, который мы вставляем, он 10 000. Соответственно, мы можем рассчитывать, что последний миллион у нас не будет дублироваться, если мы захотим повторить.


Да, но только если выставляете прямо такими же блоками.


Т. е. идентичными блоками, да?


Да, для идентичного блока считается checksum. Если checksum совпадает, значит блок уже вставили и дублировать не надо.


Я понял. И второй вопрос. Меня интересуют запросы distributed таблицы к replicated таблицам. Я так понимаю, что запрос у нас идет только к одной реплике. Можно ли как-то настроить, чтобы какие-то тяжелые запросы шли на обе реплики, чтобы часть данных оттуда, часть данных оттуда каким-то образом доставалась?


Да, можно так настроить. Это еще один способ заиспользовать больше компьютеров. Есть специальная настройка, вы ее устанавливаете. По-моему, она называется max_parallel_replicas. Что она делает? Она половину данных обрабатывает на одной реплике, половину на другой. Но сразу оговорюсь, это работает только, если при создании таблицы был указан ключ сэмплирования. В ClickHouse есть такая фича ключ сэмплирования. Вы можете посчитать там запрос не по всем данным, а по одной десятой. И если у вас в реплицированной таблице задан ключ сэмплирования, то при указании этой настройки max_parallel_replicas, он сообразит, что можно одну вторую данных посчитать там и другую половину на второй реплике. И будет использовать обе.


Не будет ли еще раз сэмплирование?


Если вы не указали при запросе сэмпл, то сэмплирования не будет. Он просто это использует для того, чтобы разделить работу по двум репликам.


Понял, спасибо!


Спасибо за доклад! У меня три вопроса. Вы говорили, что индексы размазаны, т. е. там 8 000 с чем-то. И нужно писать большими объемами. Используете ли вы какую-то предбуферизацию? Рекомендуете ли вы что-то использовать?


Это больной вопрос, потому что все норовят по одной строчке вставлять. У нас в метрике, например, очень умный батчер, который отдельные команды разрабатывает, которые много дополнительной работы проводят, поэтому в ClickHouse его нет.


Что есть? Есть буфер-таблица, куда тоже по одной строчке не надо вставлять, потому что будет тормозить на какой-то ерунде. Но если вы туда вставляете, она по диску меньше ездит. Т. е. не будет на каждую вставку делать запись на диск. И очень многие люди, которые уже более серьезно подходят к ClickHouse, они используют Kafka. У вас в Kafka lock, ваша писалка берет записи из Kafka и вставляет их в ClickHouse. Это тоже хороший вариант.


Да, т. е. можно это вручную настроить. Еще вопрос. У нас есть distributed таблица, которая управляет всеми шардами. И, например, шард с distributed таблицы умер. Это значит, что все данные у нас умерли?


Distributed таблица не хранит ничего. Если она у вас умерла, то вы просто создаете заново, и все так же работает. Главное, сохранить local_tables, в которых данные лежат, поэтому, конечно, их нужно реплицировать.


И последний вопрос. Вы говорили, что можно вручную шардировать ее. А есть ли какие-то гарантированные транзакции, что я записал туда, записал туда, а если не записалось туда, то все это отменить? Я же пишу на три разных шарда.


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


Т. е. я должен хранить это, куда я записал?


Не обязательно это все хранить, потому что distributed таблица спрашивает все шарды. Когда у вас 500 серверов, как у нас, то начинает этого уже не хватать. Потому что на 500 серверов одновременно не очень хорошо ходить. Поэтому у нас там двухуровневое шардирование. Второй уровень уже знает, куда он положил данные и он на это обращает внимание. Но до 100 серверов этого за глаза хватает, т. е. просто во все серверы сходить и забрать результат обратно.


Спасибо большое!


Как изменять данные? Можно ли там чего-то изменить, например, блок целиком вынести и заново закачать, чтобы не целиком с нуля всю таблицу?


Да, можно изменить целиком блок, точнее не блок, а всю партицию. Сейчас это месяц. Но у нас есть приоритетная задача сделать партицию произвольной. Вы берете и говорите alter table drop partition и он убирается, и вы можете обратно залить данные.


И еще есть кейсы, когда у вас какие-то данные, которые нужно обновить. Они есть и они немножко изменяются в реальном времени. Например, есть не хиты, а визиты пользователей. Т. е. пользователь пошел на одну страничку, на другую и у него длина визита растет. В ClickHouse для этого есть движок, который называется CollapsingMergeTree. Им не очень удобно пользоваться, но эту задачу он решает. И когда вы хотите что-то поменять, вы записываете две записи: первая это удалить предыдущую запись, вторая это записать новые данные. И эта таблица где-то у себя в фоне будет оптимизировать. И чуть-чуть вы можете изменять данные таким способом.


Вам нужно будет хранить всю эту строку где-то. Вы, конечно, можете сходить в ClickHouse и спросить: Какая последняя строка для этого ключа?, но это будет медленно уже.


И параллельный вопрос. Правильно ли я понимаю, что если мне нужна репликация на две точки, а не на три, то проще поставить Kafka и с нее две базы писать и не париться? Т. е. когда два дата-центра, а третьего нет.


Мы все-таки рекомендуем replicated таблицы. Почему? Потому что distributed таблица тоже умеет реплицировать.


Как replicated сделать на два ДЦ? У меня все равно получается, что если падает мастер, то писать никуда нельзя, а можно только читать. Или там какие-то простые способы? Slave сделать мастером, а потом догнать первого мастера до slave?


А с Kafka у вас как?


С Kafka я буду выливать каждую независимо. С Kafka все равно придется делать на три ДЦ.


Kafka тоже использует ZK.


На нее данных меньше надо. Но она только пару дней будет хранить, а не за всю историю, в Kafka меньше ресурсов. Но ее на три ДЦ дешевле делать, чем ClickHouse на три ДЦ.


ClickHouse не обязательно размазывать на три, вам только нужно ZK поставить.


А, все, только для quorum ZK, данные дублируются только два раза. Для quorum у нас есть ДЦ.


Почему мы еще рекомендуем replicated таблицу, а не просто в две таблицы запихивать? Потому что очень много проверок происходит, что данные именно идентичные. Если вы так будете записывать самостоятельно или через distributed таблицу, то легко получить какое-то расхождение. И потом оно уже никогда не исправится, потому что уже записали и до свидания. И не понятно разошлось или нет. А replicated таблицы непрерывно пытаются поддерживать вот эту общность и единый набор кусков.


У меня вопрос касается утилизации памяти. Как наиболее эффективно распределять ее? Сколько под instants выделять?


Про память такая история, что в ClickHouse есть такая настройка, как max_memory_usage. Это сколько вы можете отъесть, когда обрабатываете запрос. Для чего еще нужна память? Память нужна под дисковый кэш. Т. е. у ClickHouse нет какого-то хитрого кэша. Некоторые системы, как делают? Они читают o_direct с диска и как-то у себя кэшируют. ClickHouse так не делает. Какую-то часть памяти (довольно большую) нужно оставить под дисковый кэш. У вас данные, которые недавно читались с диска, будут потом из памяти прочитываться. И треть вы отводите на память, которая нужна в запросе.


Для чего ClickHouse расходует память? Если у вас запрос стриминговый, т. е. просто пройтись и что-то там посчитать, например, count, то будут единицы памяти расходоваться.


Где может понадобиться память? Когда у вас group by с большим количеством ключей. Например, вы по тем же самым referrers что-то группируете и у вас очень много различных referrers, urls. И все эти ключи нужно хранить. Если вам хватило памяти, то хорошо, а если не хватило, то есть возможность group by выполнить на диске, но это будет гораздо медленнее.


Это он сам определит?


Нужно включить.


Есть какой-то объем, который вы рекомендуете выстраивать? Например, 32 GB на ноду? Т. е., когда эффективно используется.


Чем больше, тем лучше. У нас 128 GB.


И один instance все 128 использует, да?


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


Алексей, спасибо за доклад! Вы не измеряли падение производительности при сильной фрагментации файловой системы?


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


Хотя бы примерный порядок?


Не знаю, процентов до 70 нормально будет.


Спасибо!


Добрый день! У меня два вопроса. Насколько я знаю, сейчас у ClickHouse только http-интерфейс для обмена данными с клиентом. А есть ли какой-то roadmap, чтобы сделать бинарный интерфейс?


У нас есть два интерфейса. Это http, который можно любым http-клиентом использовать, который в JDBC-драйвере используется. И есть нативный интерфейс, который мы всегда считали приватным и не хотели для него какой-то библиотеки делать. Но интерфейс этот не такой сложный. И мы поддерживаем там прямую-обратную совместимость, поэтому добрые люди использовали исходники как документацию и в Go есть, я слышал, отличный драйвер, которые нативные клиенты используют. И для C++ мой коллега сделал отдельный драйвер, который позволяет использовать нативный интерфейс и вам не нужно линковаться со всем ClickHouse, чтобы его использовать. И для других языков тоже, наверное, есть. Точно не знаю. Т. е. формально мы его считаем нашим приватным, но по факту он уже публичный. Из некоторых языков им можно пользоваться.


Спасибо! Вы говорили, что написали свою систему репликации данных. Допустим, Impala использует HDFS для репликации данных, она не делает репликацию самостоятельно. Почему вы написали репликацию, чем она лучше, чем HDFS?


Интересный вопрос. ClickHouse развивается послойно. Сначала были простые merge таблицы, потом появилась для них репликация. И вот эта схема с кусками, которая мержится, она просто так на HDFS не ложится. Наверное, можно было использовать HDFS как файловую систему и там хранить куски, но проще на локальной файловой системе это делать.


Т. е. вы напрямую не сравнивали?


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


Один кусок это будет один блок на HDFS и будет операция *opened*, если это возможно.


Т. е. использовать HDFS как хранилище?


Да. Чтобы не делать собственные репликации. Вы записали на HDFS и считайте, что оно уже реплицировано, и поддерживается отказоустойчивость.


А читать-то мы хотим с локального диска.


HDFS поддерживает локальное чтение. Вы можете узнать, на каких нодах хранятся данные и чтение запускать там, где они хранятся.


Интересная мысль, надо подумать.


Спасибо!

Подробнее..

Из песочницы Облачный СКУД ЗА и ПРОТИВ из первых рук

06.07.2020 02:17:13 | Автор: admin
Пандемия жёстко заставила каждого из нас, без исключения, если не воспользоваться, то признать до сих пор преимущественно информационную среду интернет ещё и системой жизнеобеспечения. Ведь многих сегодня интернет буквально кормит, одевает и обучает. Интернет проникает в наши дома поселяясь в чайниках, пылесосах и холодильниках. IoT internet of things это любое оборудование, бытовые приборы например, в которые встроены крошечные электронные модули для обмена данными в сети Интернет через наш домашний WiFi.

Даже дверные замки многие производители начали делать с управлением через смартфон. Очередь за системами контроля доступа и эксплуатацией зданий и сооружений. И тут я хочу обсудить известные мне ЗА и ПРОТИВ облачных СКУД, поскольку работаю в коллективе, который одну из таких систем и разрабатывает.

Обсудить, пока что в независимости от профиля объекта, будь то жильё, промышленное предприятие, склад, ТРЦ, БЦ или образовательное учреждение.

Перечислю очевидные ЗА и ПРОТИВ облачных СКУД



PRO


  • Заявки на пропуск оформляются онлайн, без необходимости заполнять бумажки и собирать подписи согласования.
  • Пропуск доступен для редактирования и управляющему, и принимающему, и СБ, причём, с онлайн уведомлением владельца пропуска в удобном ему мессенджере, СМС или эл. почте об внесённых изменениях.
  • Удобный доступ к данным СКУД для руководителя администрации, начальников охраны, отдела кадров, особенно на предприятиях с филиальной сетью, в любое время, с любого ПК с веб браузером, на мобильном устройстве. Отпуск, командировка, больничный не препятствие справится о текущих делах, глянуть статистику.
  • Внедрение на объекте без сложного проектирования. Поскольку топология веб-сервисов позволяет легко менять тех. процессы и логику, возможные ошибки первоначальной схемы легко поправить уже в процессе эксплуатации и выбрать оптимальную структуру КПП, проходных и уточнить режим объекта.
  • Для настройки и тем более для управления не требуется специальной квалификации и подготовки. Современные инструменты программирования настолько нацелены на создания программных продуктов интуитивных в использовании, что создаваемые облачные сервисы обречены быть просто управляемыми и удобными в эксплуатации.
  • Дешевизна оборудования обусловлена его практическим отсутствием. Высокопроизводительные микро-ПК Ардуино, Расберри, Оранж заменяют специализированные контроллеры. Вся логика уходит на серверную часть и в оперативную память мобильных устройств, смартфонов. Смартфоны заменяют собой привычные RFID карточки и брелки, обеспечивая экономию на расходных материалах. Открывающее воздействие на замок, турникет оказывает тот самый крохотный элемент IoT интернета вещей. Дешёвый в силу своей простоты и тиражей производства.

image

пример структуры СКУД как облачного сервиса

Как вы догадались это были аргументы в пользу веб-сервисов СКУД. Буду честен и без утайки перечислю все аргументы против применения СКУД как облачного решения.

CONTRA


  • Хранение данных пользователя в облаке. Риски утраты информации по техническим причинам, утечки третьим лицам. Снизить эти риски можно распределением микро-сервисов по большему числу ЦОД (центр обработки данных) и выбору надёжных поставщиков этой услуги с классом TIER 3 или выше.
  • Отсутствие у части пользователей смартфонов. Нежелание использовать личный смартфон для служебных целей. Для решения этой проблемы у управляющий компании есть опция печати QR пропуска на чековом принтере, что под чертой выгоднее чем выдавать брелок или карту.
  • Наличие на объекте СКУД установленной годами ранее, но исправно работающей хоть и устаревшей. В этом случае есть опция применить для интеграции штатный в веб-сервисах API (application program interface) и расширить функционал до желаемого. Тем более что к большинству известных систем контроля доступа как правило уже написаны интеграции.
  • Традиционное нежелание наёмных сотрудников отказываться от знакомых систем и технологий, неважно что в пользу более эффективных и выгодных технологических аналогов. Саботаж среднего звена на этапах согласования может и часто вынуждает руководство, собственников сдаться и отказаться от модернизации.

Но лидером контраргументов, какие я только слышал, остается классическое " а что если пропадёт интернет...". Тут у меня нет слов, и в голову приходит старый анекдот:

Я самая главная, дерзко заявила Эл. Почта, меня все читают! Нет, я главнее, негромко возразил Интернет, ты во мне живешь. Электричество тихо вздохнуло и отвернулось.

И так, приглашаю подебатировать на тему ЗА и ПРОТИВ Интернета в охранных системах, в частности СКУД. Пожалуйста, смело комментируйте с чем не согласны, буду рад услышать критику, возразить или честно согласиться. Стесняетесь высказаться публично пишите в личку.

Спасибо
Илья
Подробнее..

Блокируем заливку приватных ключей, архивов, больших файлов и не только в Gitlab CE

06.07.2020 10:05:56 | Автор: admin

Git hooks инструмент, помогающий держать в порядке ваш репозиторий. Можно настроить автоматические правила оформления ваших коммитов.


Все вы наверное знаете про pre-commit проверку вашего кода перед коммитом. Но ведь не все можно проверить перед коммитом. Некоторые ограничения хочется использоваться глобально на всем Gitlab.


Кто запутался в pre-commit и pre-receive хуках, в этом посте описываются различия между ними https://blog.gitguardian.com/git-hooks-automated-secrets-detection/ в абзаце "What are git hooks?".


Если у вас Gitlab Enterprise Edition, вы можете настроить хуки, которые описаны в посте через WEB интерфейс.


Но что делать, если у вас Gitlab Community Edition?


В этой статье будут описаны 5 pre-receive хуков, которые выполняются на сервере Gitlab Community Edition:


  • block_confidentials.sh Блокирование отправки приватных ключей и AWS токенов
  • block_file_extensions.sh Блокирование отправки архивов (Regex настраивается)
  • check-large-files.sh Блокирование отправки больших файлов (Размер настраивается)
  • reject-not-allowlist-email.sh Блокирование коммитов с email не из allow списка (Список email доменов настраивается)
  • require-issue.sh Блокирование коммитов без issue в названии (Список issue настраивается)

В основном хуки взяты из репозитория platform-samples в директории pre-receive-hooks (относится к GitHub Enterprise).


Весь исходный код серверных хуков вы можете посмотреть на Github https://github.com/patsevanton/git-server-pre-receive-hooks


Установка на Gitlab


  • Необходимо создать директорию /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/
  • Скопировать в эту директорию хуки
  • Не забыть выставить права запуска для хуков (chmod +x файл-хука)

Блокирование отправки приватных ключей и AWS токенов


В файле block_confidentials.sh настраиваем список regex_list, который описывает конфиденциальную информацию.


# Define list of REGEX to be searched and blockedregex_list=(  # block any private key file  '(\-){5}BEGIN\s?(RSA|OPENSSH|DSA|EC|PGP)?\s?PRIVATE KEY\s?(BLOCK)?(\-){5}.*'  # block AWS API Keys  'AKIA[0-9A-Z]{16}'  # block AWS Secret Access Key (TODO: adjust to not find validd Git SHA1s; false positives)  # '([^A-Za-z0-9/+=])?([A-Za-z0-9/+=]{40})([^A-Za-z0-9/+=])?'  # block confidential content  'CONFIDENTIAL')

Добавляем в репозиторий приватный ключ, делаем коммит и при git push получаем ошибку.



Блокирование отправки архивов


В файле block_file_extensions.sh настраиваем case *.zip|*.gz|*.tgz, в котором указываются расширения файлов, которые будут блокироваться.


Добавляем в репозиторий zip архив, делаем коммит и при git push получаем ошибку.



Блокирование отправки больших файлов


В файле check-large-files.sh настраиваем параметр maxsize, который указывает размер файла в мегабайтах, выше которого отправка будет блокироваться.


Добавляем в репозиторий файл больше 1 мегабайта, делаем коммит и при git push получаем ошибку.



Блокирование коммитов с email не из allow списка


В файле reject-not-allowlist-email.sh настраиваем список email-доменов, для которых разрешены коммиты.


declare -a DOMAIN_ARRAY=("group1.com" "group2.com")

Меняем почту в git на ту, которой нет в разрешенном списке.


git config user.email user1@group3.com

Добавляем в репозиторий любой файл, делаем коммит и при git push получаем ошибку.



Блокирование коммитов без issue в названии


Этот серверный хук был взят из блога Majilesh.


В файле require-issue.sh настраиваем список commit_format, для которых разрешены коммиты.


commit_format="(JIRA|PROJECTKEY|MULE|ECOM|SAP|XLR-[1-9]+Merge)"

Добавляем в репозиторий любой файл, делаем коммит, в названии которого нет слов из commit_format и при git push получаем ошибку.



Надеюсь что мой пост сподвигнет сообщество развивать направление серверных хуков.


Telegram чат по Gitlab https://t.me/ru_gitlab

Подробнее..

Dell EMC PowerStore коротко о нашей новейшей СХД корпоративного класса

07.07.2020 12:09:02 | Автор: admin
Совсем недавно наша компания представила новый продукт Dell EMC PowerStore. Это универсальная платформа с ориентированным на производительность дизайном, обеспечивающим многомерное масштабирование, постоянное сокращение данных (компрессия и дедупликация) и поддержку носителей нового поколения. PowerStore использует микросервисную архитектуру, передовые технологии хранения и интегрированное машинное обучение.

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




Преимущества новых систем хранения:


  • Современная микросервисная архитектура. Система базируется на контейнерной архитектуре, когда отдельные компоненты ОС выделяются в отдельные микросервисы. Микросервисная архитектура обеспечивает переносимость функций и быстрое внедрение нового функционала. Такая архитектура позволяет быстро адаптировать ранее написанный функционал на новую платформу т.к. микросервисы автономны и не влияют друг на друга, микросервисная архитектура позволяет обеспечить более высокую надежность работы всей системы по сравнению с монолитной архитектурой. Например, обновление микрокода часто затрагивает только отдельные модули, а не всю систему (или ее ядро) и, как следствие, проходит более гладко.
  • Использование передовых технологий хранения данных. Поддержка памяти Storage Class Memory (SCM) Intel Optane и NVMe All-Flash позволяет устранить узкие места в системе и существенно увеличить производительности и сократить время отклика системы.
  • Непрерывное сокращение объема данных на лету. Всегда включенные механизмы компрессии и дедупликации данных, позволяют уменьшить объёмы, занимаемые данными внутри системы и оптимизировать хранение. Это позволяет сократить затраты на приобретение и эксплуатацию системы и повысить эффективность работы.
  • Гибкая масштабируемость решения. Архитектура решений Dell EMC PowerStore поддерживает как вертикальное, так и горизонтальное масштабирование, благодаря чему вы можете эффективно планировать расширение инфраструктуры наращивая ёмкость или вычислительные ресурсы независимо друг от друга.
  • Встроенные механизмы защиты данных. Системы PowerStore обладают широким спектром встроенных механизмов защиты данных от мгновенных снимков и репликации до шифрования данных и интеграции с антивирусными программами. Система также широко интегрируется с внешними решениями, как от Dell Technologies, так и от других производителей.
  • AppsON. Благодаря интегрированному в систему гипервизору VMware ESX заказчики могут запускать пользовательские виртуальные машины непосредственно внутри системы.
  • Интеграция с VMware. PowerStore предназначен для глубокой интеграции с VMware vSphere. Интеграция включает поддержку VAAI и VASA, уведомления о событиях, управление снимками, vVols, а также обнаружение и мониторинг виртуальных машин в PowerStore Manager.
  • Унифицированный доступ к данным. PowerStore обеспечивает хранение данных приложений в различных форматах, от физических и виртуальных томов до контейнеров и традиционных файлов благодаря возможности работы по множеству протоколов блочных, файловых и VMware vSphere Virtual Volumes (vVols). Эта способность обеспечивает высокую гибкость данной системы и позволяет ИТ-отделам упростить и консолидировать инфраструктуру.
  • Простой, современный интерфейс управления. Интерфейс управления системой PowerStore Manager разрабатывался на основе требований наших заказчиков к простоте управления системой. Это web-интерфейс, запускающийся на контроллерах системы PowerStore. Доступен по протоколу HTML5 и не требует установки дополнительных плагинов.
  • Программируемая инфраструктура. Упрощает разработку приложений и сокращает сроки их развёртывания с нескольких дней до нескольких секунд благодаря интеграции с VMware и поддержке ведущих сред управления и оркестрации, включая Kubernetes, Ansible и VMware vRealize Orchestrator.
  • Интеллектуальная автоматизация. Встроенные алгоритмы машинного обучения автоматизируют трудоемкие рабочие процессы: такие как начальное планирование и размещение томов, миграция данных, балансирование нагрузки и устранение проблем
  • Аналитическая информация об инфраструктуре. Программное обеспечение Dell EMC CloudIQ для мониторинга и анализа хранилищ сочетает в себе преимущества машинного обучения и человеческого интеллекта для анализа производительности и ёмкости систем в режиме реального времени, а также хранения исторических данных, чтобы получить единое представление об инфраструктуре Dell EMC. Компания Dell Technologies планирует интегрировать CloudIQ с полным портфелем своих решений для еще более глубокой аналитики.

Платформа представлена двумя типами систем:

  1. PowerStore T выступает в качестве классической СХД.
  2. PowerStore X выступает как гиперконвергентное решение, позволяющее запускать виртуальные машины заказчика, совмещенное с выделенной, классической СХД.

Благодаря интегрированным возможностям VMware ESXi, модели PowerStore X предоставляют возможность размещать приложения с интенсивным вводом-выводом непосредственно внутри системы PowerStore. При использовании встроенных механизмов VMware (vMotion) обеспечивается возможность перемещения приложений между системой хранения PowerStore и внешними решениями. Встроенный гипервизор VMware ESXi запускает приложения заказчиков вместе с операционной системой PowerStore в виде виртуальных машин VMware. Этот инновационный дизайн идеально подходит для приложений с большим объёмом хранилища, обеспечивая дополнительные вычислительные и высокопроизводительные хранилища для существующей среды или любого сценария, в котором плотность, производительность и доступность являются основными факторами.

Явными примерами, когда AppsON идеально решает задачи наших заказчиков, являются:

  • Выделенная инфраструктура для одного приложения. Например, для базы данных, которой требуется выделенный сервер, СХД, а также какая-то дополнительная обвязка, например, для резервного копирования. В этом случае вы можете купить одну единственную систему PowerStore которая закроет все задачи, т.к. само приложение и сервер резервного копирования можно развернуть в рамках узла PowerStore без необходимости в дополнительной инфраструктуре.
  • ROBO (удаленные филиалы и офисы). Многие заказчики сталкиваются с задачей в каком-то виде реплицировать инфраструктуру основного ЦОД на периферию, чтобы обеспечить работу удаленных филиалов своих компаний. Раньше приходилось для этого покупать отдельные сервера, СХД, коммутаторы для их соединения, а также ломать голову на тему того, как защитить инфраструктуру и самое главное данные. Мы предлагаем, как и в предыдущем примере, пойти по пути консолидации инфраструктуры в рамках одного решения Dell EMC PowerStore. Вы получите полностью готовую инфраструктуру в рамках шасси в 2U, состоящую из пары отказоустойчивых серверов, соединенных с высокоскоростной СХД.

Оба типа систем представлены в виде линейки моделей с разными техническими характеристиками:



Важной особенностью систем PowerStore является возможность модернизации уже купленной системы в будущем. Вот как это можно сделать.

  • Традиционный апгрейд младших моделей до старших позволяет избегать лишних инвестиций на этапе закупки системы: нет необходимости сразу покупать дорогое решение, потенциал которого в полной мере раскроется только через несколько лет. Процедура апгрейда это штатная замена одних контроллеров на другие, она выполняется без остановки доступа к данным.
  • Благодаря правильно выбранной архитектуре систему можно будет модернизировать до нового поколения, что позволит поддерживать её в актуальном состоянии и увеличить срок эксплуатации.
  • Есть способ заложить возможность модернизации системы на этапе закупки. Для этого существует специальная опция Anytime Upgrade, которая позволяет либо актуализировать систему за счёт модернизации её до нового поколения, либо модернизировать систему до более старшей и более производительной модели.

Лицензирование


Dell EMC PowerStore лицензируется по модели Всё включено. Весь доступный функционал заказчик получает вместе с системой без дополнительных инвестиций. По мере выхода нового функционала массива он также станет доступен заказчикам после модернизации микрокода.

Оптимизация физического объема данных


Dell EMC PowerStore включает несколько методов повышения эффективности хранения данных за счёт сокращения используемого данными физического объёма:

  • тонкое выделение пространства;
  • компрессия имеет аппаратную реализацию и выполняется при помощи отдельного физического чипа, вследствие чего процесс не оказывает влияния на производительность системы;
  • дедупликация данных позволяет не хранить только уникальные данные, без повторов.

Динамические пулы


Dell EMC PowerStore оснащается системой RAID на основе экстентов для обработки сбоев дисков. Большое количество элементов RAID представляет собой единое логическое пространство, формирующее пул, с которым работает конечный пользователь.

Архитектура динамический RAID обеспечивает 5 основных преимуществ:

  • сокращение времени восстановления после сбоя диска путем параллельного восстановления с множества дисков;
  • равномерное распределение запросов записи на все диски;
  • возможность смешивать диски разного объема в одном пуле;
  • возможность расширения емкости системы путем добавления дисков по одному и более;
  • возможность отказаться от физически выделенного диска горячего резерва позволяет системе перестраивать блоки данных с использованием всех исправных дисков.



High availability


СХД Dell EMC PowerStore полностью защищена от сбоев и включает ряд методов обеспечения высокой доступности. Данные методы предназначены для противостояния сбоям компонентов в самой системе и во внешней инфраструктуре, таких как перебои в сети или отключение питания. В случае сбоя отдельного компонента система хранения продолжает обслуживать данные. Система также может противостоять нескольким сбоям, если они происходят в отдельных наборах компонентов. После того, как администратор получит уведомление о сбое, он может заказать и заменить неисправный компонент без последствий.

NVMe SCM


Носители хранения данных SCM (Storage Class Memory) это высокопроизводительные энергонезависимые накопители, созданные на основе технологии Intel Optane. Накопители NVMe SCM имеют меньшую задержку и улучшенную производительность по сравнению с другими SSD. NVMe это протокол, который позволяет осуществлять доступ напрямую через шину PCIe. NVMe разработан с учетом низкой задержки высокопроизводительных носителей. Накопители NVMe SCM служат уровнем хранения для PowerStore, используются для пользовательских данных или метаданных. На данный момент доступны объёмы в 375 и 750 ГБ.

NVMе NVRAM


NVMe NVRAM это высокопроизводительные накопители, используемые для улучшения системы кэширования PowerStore. Они доступны с обоих контроллеров системы и позволяют системе легко кэшировать входящие записи. Накопители работают на скоростях DRAM по PCIe, обеспечивая исключительную производительность. Их конструкция позволяет им функционировать как энергонезависимые носители, и PowerStore может быстро сохранять входящие записи и подтверждать операции хосту без оповещения второго контроллера. Хранилища данных устанавливаются парами для зеркалирования данных между собой на случай аппаратного сбоя.

Данный подход позволил существенным образом ускорить работу системы хранения данных:

  • во-первых, контроллерам не надо тратить такты своих ЦП на синхронизацию данных кэш-памяти друг с другом;
  • во-вторых, вся запись на накопители происходит блоком в 2 МБ, т.к. система копит этот объем данных перед тем, как записать данные на диски. Таким образом, запись из случайной превратилась в последовательную. Как вы сами понимаете, такой подход существенным образом снижает нагрузку на хранилища данных и сами контроллеры.



Кластеризация


Каждое устройство Dell EMC PowerStore развёртывается в виде одного из узлов кластера, т.к. кластеризация является частью архитектуры данной платформы. На текущий момент в единый кластер можно объединить не более четырех узлов PowerStore. При развертывании кластера с несколькими устройствами эту задачу можно выполнить во время процесса начальной настройки или в будущем добавить устройства в уже существующий кластер. Кластер PowerStore можно уменьшить, удалив устройства из существующего кластера, фактически разделив один большой кластер на два более маленьких.



Кластеризация устройств Dell EMC PowerStore даёт много преимуществ.

  • Scale-Out масштабирование для увеличения количества ресурсов системы за счёт добавления дополнительных вычислительных узлов процессора, памяти, ёмкости и интерфейсов подключения к хостам.
  • Независимое увеличение ресурсов хранения или вычислительных ресурсов.
  • Централизованное управление много узлового кластера.
  • Автоматическая балансировка нагрузки между узлами кластера.
  • Повышенная надёжность и отказоустойчивость.

PowerStore Manager


PowerStore Manager предоставляет администраторам СХД простой и интуитивно понятный интерфейс для настройки и управления кластером. Он основан на HTML5, не требует установки дополнительного программного обеспечения на клиенте и помогает выполнить следующие задачи:

  • Начальная настройка нового узла PowerStore.
  • Добавление или удаление узлов из существующего кластера.
  • Управление ресурсами кластера.

мкость кластера является агрегацией ёмкостей отдельных узлов кластера. Статистика по экономии доступна для всего кластера целиком.

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

Вместо заключения


На этом краткий рассказ о Dell EMC PowerStore мы завершаем. В данной статье мы разобрали основные моменты, относящиеся к технике и экономике, которые надо понимать при планировании закупки систем PowerStore от кластеризации до лицензирования и планирования будущих апгрейдов. Много технических моментов осталось за кадром, и мы с удовольствием вам про них расскажем либо в следующих статьях, либо при общении со специалистами отдела продаж.

В заключении статьи хочется отметить, что первые проданные системы уже развернуты в ЦОД-ах наших заказчиков, дистрибьюторы и партнеры закупили демо-системы и готовы показывать их вам. Если система вызывала у вас интерес смело обращайтесь к нашим партнёрам и представителям для проработки ваших проектов.
Подробнее..

Я не понимаю, что хочу. Как пользователю сформулировать требования к CRM

07.07.2020 14:13:48 | Автор: admin
Когда кто-то трогает крестик, должен плакать персиковый медвежонок*, это, пожалуй, самое милое требование из тех, что мне приходилось встречать (но, к счастью, не реализовывать). Оно было сформулировано сотрудницей с 12 годами опыта работы в одной компании. Вы поняли, что ей нужно (ответ в конце)? Уверенное второе место занимает это: Биллинг должен запускаться по моему желанию, желание выражается на мобильнике**.

Действительно, далёкие от IT пользователи зачастую не могут сформулировать свои требования и ведут себя с разработчиками довольно странно. Поэтому мы решили написать доступную для всех статью: простым пользователям и неайтишному бизнесу она поможет легко сформулировать требования, ну а нам, айтишникам, тема на обсудить и поделиться опытом.


Пользователь избегает ответственности за требования


Если посмотреть те запросы, которые люди пишут о CRM в социальных сетях или в профильных сообществах, есть чему удивиться. Множество возмущённых постов о том, что нельзя найти CRM для длинных продаж, дистрибуции машинного масла, агентства наружной рекламы и т.д. И если человек занимается оптовыми продажами сена, то они ищут именно CRM Seno version и никак иначе. А вот в процессе общения с вендором такие запросы как-то сразу отпадают, потому что человек, выбирающий CRM, погружается в тему и понимает, что современные CRM-системы способны решить задачи практически любого бизнеса дело не в отраслевой версии, а в настройках и индивидуальных доработках.

Так откуда возникают неадекватные требования?

  • Главная причина непонимание сущности CRM-системы как технологии. Любая современная CRM-система в своей основе имеет множество разных таблиц, которые между собой связаны ключевыми полями с определёнными значениями (кто не знаком с СУБД, но когда-то работал с MS Access, легко вспомнит эту визуализацию). Поверх этих таблиц строится интерфейс: десктопный или в вебе, без разницы. Работая с интерфейсом, вы фактически работаете с теми самыми таблицами. Как правило, задачи абсолютно любого бизнеса можно решить с помощью настройки интерфейса, создания новых объектов и новых связей в совокупности с одновременным обеспечением логики их взаимодействия. (доработка).

    Да, бывает, что сфера деятельности компании требует какие-то особенные решения: медицина, строительство, недвижимость, инженерное дело. Для них существуют свои профильные решения (например, RegionSoft CRM Media для телерадиохолдингов и операторов наружной рекламы там особенным образом реализованы и медиапланирование, и работа с монтажными листами и эфирными справками, и управление местами размещения рекламы).

    Но в целом компании малого бизнеса могут использовать CRM-систему даже без доработок и покрывать все нужды оперативной работы. Именно потому что CRM создаётся как универсальное решение для автоматизации бизнеса. А то, насколько она будет эффективна для вашей компании, зависит от того, как она будет настроена и наполнена данными (например, в RegionSoft CRM есть несколько классных инструментов, которые можно адаптировать точно под нужды конкретного бизнеса и даже его отделов: редактор бизнес-процессов, настраиваемый калькулятор для построения расчётов параметров продукции, механизм для настройки сложных KPI и это подходящие механизмы для любой компании).
  • Представитель бизнеса о CRM знает от других, мнение основано на чужом негативном опыте. Он полагает, что и с ним случится что-то подобное, не подозревая, что его знакомый никогда не скажет я не разобрался в CRM или я зажал деньги на внедрение и обучение, а теперь страдаю, нет, он обвинит разработчика или вендора втюхали мне эту CRM, продали и в кусты и т.д. Такие ребята нередко решают, что вендор должен тратить часы времени сотрудников совершенно бесплатно (не могу понять, почему они же не требуют бесплатного обслуживания и ежедневной мойки автомобиля от завода-изготовителя или дилера, а спокойно оплачивают стоимость ТО официального дилера.
  • Потенциальные клиенты считают, что раз на рынке есть кто-то, кто предлагает CRM бесплатно (с кучей ограничений и звёздочек), то и остальные должны просто раздавать CRM-системы. Бесплатные CRM в Яндексе ищут около 4000 человек ежемесячно. На что они надеются непонятно, ведь по сути любая бесплатная CRM, если она рассчитана более чем на одного человека, всего лишь урезанная демо-версия и маркетинговый инструмент.

Есть и другие причины, но эти три идут с большим отрывом. С такими клиентами работать довольно непросто, поскольку у них уже есть сформированный образ идеальной по их мнению CRM и они нередко ждут ответа на свой вопрос типа: Нет, вы мне дадите CRM для продаж холодильного торгового оборудования марки Север или мне звонить в Германию и заказывать SAP?. При этом бюджета на внедрение CRM хватит разве что на звонок в эту самую Германию. Звучит немного зло, но на самом деле идти с ультиматумом к разработчикам CRM гораздо менее продуктивно, чем обсуждать требования и прислушиваться к опытным внедренцам.

Как формулировать требования?


Функциональные требования


Определите, что вам нужно улучшить в компании это будет вашим ключевым требованием к CRM-системе. Можно выделить четыре наиболее распространенные задачи, для решения которых компании задумываются о покупке CRM.

  1. Повышение эффективности работы. Если команда продаж в первую очередь и вся компания в целом увязла в администрировании, упускает важные события и теряет клиентов, забывает выполнить задачи в срок, то необходима помощь программы в управлении временем и задачами. А это значит, что среди ваших первых требований должны быть классная карточка клиента, разнообразные планировщики и возможность быстро собирать информацию по клиентам в единой базе. Довольно стандартные требования. На этом этапе можно предъявить дополнительное требование автоматизацию бизнес-процессов, которая упорядочивает рутину в бизнесе любого размера.
  2. Повышение объёма продаж. Если вам нужно больше продаж, особенно в кризис, который тут кружит над нашими уже седыми от нервов головами, то у вас есть ключевые подзадачи: сбор полной информации о клиенте, сегментация и персонализация обращений к клиентам, быстрая работа с оформлением сделки и информативная воронка продаж. Это всё тоже есть в стандартных CRM-системах.
  3. Отслеживание эффективности работников (не путать с контролем времени сотрудников, мы на этом поле не играем!). Вот здесь всё уже интереснее. Найти CRM, которая решит две предыдущие задачи, очень просто, найти CRM с KPI сильно сложнее, найти CRM с настоящим, многокритериальным, аналитическим механизмом KPI совсем непросто (если ищете, то у нас есть RegionSoft CRM Professional 7.0 и выше, а в ней KPI). Если в выбранной вами CRM-системе нет системы KPI, вы можете попросить такую доработку, однако она скорее всего будет довольно дорогой, потому что это практически отдельный модуль для любого ПО.
  4. Безопасность. На первый взгляд, CRM не относится к инструментам обеспечения корпоративной безопасности. Но автоматизация без управления безопасностью выглядит несостоятельно. Нередко к выбору CRM приводит желание руководителя избавиться от серых схем, откатов и своих персональных клиентов у продажников. CRM-система хранит данные, сохраняет клиентскую базу от попыток копирования и передачи третьим лицам, благодаря разделению прав доступа помогает контролировать круг клиентов и компетенций каждого сотрудника. И заметьте вы контролируете и делаете безопасной непосредственно рабочую деятельность, а не время сотрудников на работе.

Как правило, требования формулируются не по одной из перечисленных задач, а по нескольким. Это справедливо: раз современная CRM давно стала CRM++, почему бы не использовать её возможности не только для отдела продаж, но и для всей компании сразу. Например, календарём, телефонией, планировщиками, записями о клиентах и бизнес-процессами могут пользоваться все сотрудники компании. Как итог вся команда собрана в одном интерфейсе. Оптимальный путь, особенно сейчас, в условиях удалённой и частично удалённой работы.

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

Дополнительные требования к CRM


У малого бизнеса сегодня такая ситуация, что эти самые дополнительные требования обретают первостепенное значение, потому что CRM заработает не сразу, а вот заплатить нужно здесь и сейчас, интегрировать рабочие сервисы нужно сразу, обучить сотрудников немедленно. В целом всё это сводится к затратам.

Как оценивать стоимость CRM?


У нас была большая статья о том, сколько стоит CRM, но там изложен универсальный подход, который можно применить и для ИП на 3 человек, и для оператора связи на 1500 сотрудников. Для малого бизнеса ситуация выглядит несколько иначе и тем более мы призываем вас посмотреть на неё иначе в условиях нынешнего кризиса.

Итак, вам нужна CRM и у вас в компании 10 сотрудников, каждого из которых вы хотите подключить к единому информационному ресурсу компании пусть к RegionSoft CRM Professional (мы не имеет права рассматривать чужие решения).

Если вы решите купить CRM, то заплатите за все лицензии один раз 134 700 рублей (по состоянию на июль 2020 года). Это, с одной стороны, оптимальный путь: заплатил и забыл, эти 134.7 тыс. не прирастут ни через год, ни через три. Если вы, например, арендуете облачную CRM, то в первый месяц вы заплатите всего 9000 рублей, но через год это будет уже 108 000, через два 216 000, через три 324 000 (и то, если обойдётся без ежегодной индексации цен).

Но! Мы знаем, что у бизнеса сейчас может не быть 134 700, а CRM в кризис нужна больше чем когда-либо. Поэтому у нас есть рассрочка 26 940 в месяц и аренда 11 233 в месяц с правом выкупа. При этом вы получаете не какой-то уменьшенный пакет функций, а всё ту же мощную редакцию.

Мы сделали эту выкладку далеко не только ради рекламы. Если вы приходите к вендору, стоит правильно формулировать ценовые требования.

  • Не просите бесплатную версию вы по факту продадите её сами себе (потому что это бесплатно) и попадёте на маркетинговый крючок: в итоге всё равно купите, но вас немного задолбают общением, а вы потом задолбаетесь из-за ограничений функциональности.
  • Если вы не готовы оплатить год аренды или всю стоимость решения on-premise, обсуждайте возможность рассрочки и дискретных платежей.
  • Никогда не заказывайте доработку сразу, если вы не уверены, что функция понадобится прямо сейчас и её нет в CRM. Лучше начните использовать CRM-систему и постепенно сформулируйте, что вам необходимо доработать и как эта доработка будет использоваться в компании.
  • Уточните у вендора, какие дополнительные затраты обязательны: у кого-то это платный внешний почтовый клиент, обязательное подключение к единственному оператору IP-телефонии, пакет технической поддержки и проч. Эти затраты могут стать внезапным и неприятным сюрпризом.
  • Узнайте стоимость внедрения и обучения в 90% случаев это оправданные расходы, которые окупаются благодаря быстрому и правильному старту работы в CRM-системе.

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

Итак, мы с вами разобрались с двумя самыми важными требованиями: функциональностью CRM-системы и с деньгами, которые предстоит за неё заплатить.

Какие ещё требования могут быть к CRM?


  • Нагрузка на CRM-систему. Расскажите вендору, какое количество информации планируется ежедневно вносить в базу, как она должна храниться и какие резервные копии иметь. Для большинства современных CRM это по-прежнему принципиальный момент, который может сказаться на скорости работы, стоимости, модели поставки и т.д.
  • Возможные настройки. Обговорите заранее, какие настройки для вас особенно важны. Это может быть воронка продаж, почтовый клиент, рассылки, обязательно распределение прав доступа и т.д. Как правило, тут пожелания бывают самые специфические.
  • Совместимость с существующей инфраструктурой. Уточните, какие интеграции возможны, как организована телефония, какое серверное оборудование требуется и требуется ли (для десктопных CRM-систем). Посмотрите, с каким ПО из вашего зоопарка пересекается CRM и откажитесь от него для экономии и наведения порядка в делах.
  • Безопасность. Если у вас есть особые требования к безопасности, обговорите их отдельно, поскольку не все они могут быть выполнены для некоторых типов поставки ПО. Уточните сроки и периодичность создания бэкапов, а также уточните, платная эта услуга или нет.
  • Техническая поддержка. Мы рекомендуем у всех поставщиков CRM на первый год покупать пакет платной приоритетной поддержки так вам будет гораздо спокойнее. В любом случае, убедитесь, что техническая поддержка есть и уточните границы её оказания.
  • Облако или десктоп. Вечный спор из разряда Apple vs Samsung, Canon vs Nikon, Linux vs Windows. Если коротко, то десктоп в конечном итоге дешевле, местами безопаснее и быстрее в работе, лицензии принадлежат вам и не пропадут вместе с вендором. Облако удобнее для молодых, начинающих команд, когда не требуется персональное внедрение или доработка. Масштабируемость у обоих типов поставки CRM одинаковая.

Главные ошибки пользователей при описании требований


  • Упираться в мелочи. Как правило, почти любую мелочь можно настроить, гораздо важнее обратить внимание на то, как CRM согласуется с вашими бизнес-процессами. Если вы считаете самым важным в CRM дашборд с данными или возможность заменить лого разработчика на своё (кстати, в RegionSoft CRM легко), пообщайтесь с коллегами они помогут вам собрать требования, весьма красочно описав все недостатки своих бизнес-процессов.
  • Превращать требования к ПО в список покупок. Вы внимательно читаете все отзывы, социальные сети, Хабр, другие порталы, смотрите демо-версии всех CRM-систем и методично записываете всё, что вас хоть как-то заинтересовало, а затем весь этот длинный список вываливаете на наиболее подходящего вендора. А он, бедный, не понимает, почему должен разработать корпоративный портал, систему управления претензиями, модуль бухучёта и систему контроля трафика и документооборота для небольшой торговой компании в одном флаконе.

Выбирайте только то, что вам реально нужно и с чем вы можете работать. Потому что мы для вас при определённом уровне оплаты можем и экраноплан спроектировать, но а) это будет дорого; б) зачем он вам? В общем, выбирайте CRM-систему для нормальной рабочей жизни, а не для любования набором модулей и возможностей это может просто не окупиться.

  • Включать в требования фантазии и желания. Указывайте в требованиях то, что вы реально хотите сделать в бизнесе и будете использовать; задачи, поставленные в вакууме и в отрыве от реальности, причинят вред: вы убьёте время на их обсуждение и не получите результат.
  • Говорить с вендором, как с роботом. Если вы общаетесь непосредственно с разработчиком CRM (а не с партнёрской сетью), то знайте: мы не только программисты и инженеры, мы прежде всего такой же бизнес, как и вы. Поэтому расскажите о ваших проблемах, мы их отлично поймём и подскажем, как CRM эти проблемы решит. Мы не просто поставщики решений, в большинстве случаев мы сочетаем рассказ о CRM с разбором проблем вашего бизнеса. Поэтому говорите с разработчиками на обычном, человеческом языке. Скажите, почему вам вдруг стала интересна CRM-система и мы объясним вам, как её внедрить лучшим образом.
  • Быть негибким и упрямым в каждой формулировке. Обращайте внимание на то, как вендор предлагает решать ваши задачи у него уже есть опыт работы в сотнях проектах автоматизации и его инженеры нередко предлагают наиболее эффективное решение из всех возможных. Например, клиент может настаивать на требовании нотации BPMN 2.0 для описания процессов (потому что её хорошо продавали на конференции для CIO) и не признавать альтернатив, а потом попробовать удобный нативный редактор бизнес-процессов и убедиться, что с ним ВСЕ его сотрудники смогут справиться с бизнес-процессами. Выбирать удобные и практичные, а не модные и дорогие решения идеальная практика для малого бизнеса, который тратит на автоматизацию свои деньги, а не бездонный бюджет корпорации.
  • Говорить о CRM в целом, а не о конкретной системе. Во время общения с вендором говорите именно о его CRM-системе, запросите подробную презентацию, задавайте подробные вопросы по существу. Так вы сможете понять, какие задачи вашего бизнеса сможет решить эта конкретная CRM-система.

Хорошо спланированный сбор требований залог успеха в выборе CRM-системы. Если вы приравняете требования к хотелкам и советам друга, вы получите плохо приспособленную для вашего бизнеса CRM-систему, которая и ресурсы высосет, и ощутимой выгоды не принесёт. Каждый проект внедрения это трудозатраты и ресурсы с обеих сторон, поэтому с внедренцами лучше быть честными, чтобы не загубить весь проект в самом начале. Ваш большой друг разработчик CRM, которому, между прочим, не выгодно предлагать свой софт под любые требования. Ему важно, чтобы вы успешно работали в системе, а не просто купили её. Во всяком случае, это важно для нас. Давайте дружить!


И напоследок, простой способ определить, удалось ли внедрение CRM: если вы используете CRM и скорость бизнес-процессов выросла, внедрение проведено правильно и ваш бизнес стал эффективнее.



(осторожно, 77 МБ)

Расшифровка требований из вступления
*Когда кто-то трогает крестик, должен плакать персиковый медвежонок нужно было прикрутить донт лив попап картинку со скидкой, которая всплывала бы при попытке закрыть страницу. Плачущий медвежонок казался самым убедительным зверем.

**Биллинг должен запускаться по моему желанию, желание выражается на мобильнике биллинг должен запускаться вручную сотрудником АСУ после получения от сотрудника коммерции СМС о завершении расчётов с партнёрами.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru