Подключение к Kafka в изолированном окружении

Есть изолированное от внешнего мира окружение в GCP с кластером Kafka, который живет в GKE. Kafka используется как внутри GKE кластера, так и виртуальными машинами, которым Kafka выставлена через внутренний балансировщик. Часть пользователей не приемлют использование консольных команд чтобы подключиться к Kafka и хотят пользоваться привычными им инструментами вроде Offset Explorer и ему подобными.

Итого у нас есть три брокера Kafka, которые доступны внутри кластера как kafka-0.kafka-headless.default.svc.cluster.local:9092, kafka-1.kafka-headless.default.svc.cluster.local:9092 и kafka-2.kafka-headless.default.svc.cluster.local:9092. Для виртуальных машин создано три балансировщика с адресами 172.16.0.16:19092, 172.16.0.17:19092 и 172.16.0.18:19092.

Если просто пробросить порты на локальную машину, то ничего работать не будет, т.к. после подключения к Kafka брокеру клиент получит метаданные в которых будет фигурировать Kafka advertised listeners и клиент будет пытаться подключиться к ним вместо работы с проброшенными портами.

Лимиты памяти в LXC для CGroupV2

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

Для начала настроил сколько RAM и SWAP может использовать каждый из контейнеров.

Первые впечатления от Backup for GKE

В рамках ликбеза потрогал немного Backup for GKE чтобы понять чем он отличается от привычного Velero. На данный момент времени он в preview и часть выводов может стать неактуальными в будущем.

Первое что бросается в глаза это его ценообразование - оно зависит не только от объема данных, которые попадают в бэкап, но и от количества подов, которые бэкапятся. Т.е. если у вас условно в среднем 30 подов в месяц, то вам нужно заплатить около 30$ за backup management, плюс стоимость хранения данных. В этом плане Velero выигрывает, т.к. там в основном стоимость только за хранение данных.

Далее его региональная доступность - сейчас он поддерживается только в некоторых регионах, но при этом создать бэкапить дает кластера и в неподдерживаемых регионах. Но вот восстановить бэкап в тот же кластер уже не получится - обязательно проверяйте список поддерживаемых регионов через gcloud beta container backup-restore locations list.

Сравнение gcloud storage и gsutil

Недавно команда gcloud storage вышла в GA и я решил проверить насколько ее производительность отличается от gsutil. Для тестов нашелся GCS бакет с примерно 21k мелких объектов (средний размер 24kB), которые сжаты gzip.

Запускать тесты буду в e2-standard-2 VM (2 vCPU / 8 GB). Текущая версия Google SDK:

$ gcloud version
Google Cloud SDK 403.0.0
alpha 2022.09.20
beta 2022.09.20
bq 2.0.77
bundled-python3-unix 3.9.12
core 2022.09.20
gcloud-crc32c 1.0.0
gsutil 5.13

Чтобы не зависеть от скорости работы блочного устройства тесты буду выполнять на ramfs.

$ sudo mkdir /mnt/ramdisk
$ sudo mount -t ramfs none /mnt/ramdisk
$ sudo chmod 777 /mnt/ramdisk
$ cd /mnt/ramdisk
$ mkdir test1 test2

Копирование данных через gcloud storage cp

$ cd /mnt/ramdisk/test1/
$ time gcloud storage cp -r gs://BUCKET/SAMPLE/DATA/* .

[skipped output]

  Completed files 21000/21000 | 448.9MiB/448.9MiB | 1.5MiB/s

Average throughput: 1.5MiB/s

real    4m54.065s
user    9m4.797s
sys     0m30.854s

Копирование данных через gsutil cp (используется многопоточность)

$ cd /mnt/ramdisk/test2/
$ time gsutil -m cp -r gs://BUCKET/SAMPLE/DATA/* .

[skipped output]

Operation completed over 21.0k objects/448.9 MiB.

real    5m58.861s
user    10m8.143s
sys     1m18.350s

В моем тесте копирование мелких объектов c использованием gcloud storage быстрее gsutil примерно на 18%. Пока что gcloud storage не заменит полностью gsutil, но для простых операций стоит использовать её.

Раздельный SSID для Huawei LG8245X6-50

С некоторых пор домашний интернет обеспечивает роутер Huawei LG8245X6-50 с поддержкой Wifi 6 (802.11ax). В комнатах, которые прилегают к шкафу с роутером, интернет работает стабильно, но в дальней комнате из-за обилия стен сигнал был в районе от -75dBm до -85dBm. В таких условиях ни о какой надёжной работе сети говорить не приходится (считается что приемлемый уровень сигнала должен в районе -65dBm).

Из коробки роутер идет с одинаковым SSID для 2.4GHz и 5GHz что с одной стороны должно упрощать жизнь, если 5Ghz не "добивает", но 2.4GHz работает нормально (5GHz хуже "пробивает" стены, особенно если они из железобетона). Но в моём случае в зоне слабого сигнала клиенты постоянно "скачут" с 2.4GHz на 5GHz и обратно.

Чтобы этого не происходило нужно присвоить разные SSID для разных частот. И тут кроется проблема с Huawei LG8245X6-50 - админка не дает переименовать SSID для сети 5Ghz. Поле имени копирует настройки с 2.4GHz и не даёт сменить отдельно. Чтобы обойти это ограничение достаточно завести по дополнительному SSID для 2.4GHz и 5GHz с разными именами, а после деактивировать изначальный SSID.

Обновления репозитария - июль 2022

Добавил в свой репозитарий поддержку Ubuntu Jammy (22.04) и собрал пакеты Midnight Commander 4.8.28 для архитектур amd64, armhf и arm64.

Удалил Debian Stretch (LTS поддержка закончилась вчера) и Ubuntu Hirsute (поддержка закончилась еще в январе, но руки не доходили заняться).

Настройка Google Cloud Ops Agent для Nextcloud

В процессе настройки отправки логов Nextcloud в Google Cloud Logging довелось поработать с Google Cloud Ops Agent. Это относительно новый агент, который отвечает и за логи и за метрики.

Nextcloud пишет структурированные логи в JSON формате так что возиться с регулярками не придется. Одна запись выглядит примерно так:

{
  "reqId": "fA6aIAL7fObKyDA2YeDq",
  "level": 2,
  "time": "2022-06-21T06:55:18+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "news",
  "method": "",
  "url": "--",
  "message": "https://[skipped]/data/rss read error : Server error: `GET https://[skipped]/data/rss` resulted in a `500 Internal Server Error` response:\n<html>\r\n<head><title>500 Internal Server Error</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>500 Internal Server E (truncated...)\n",
  "userAgent": "--",
  "version": "23.0.5.1"
}

Для начала нужно вытащить timestamp и severity. Timestamp буду брать из поля time, а severity из поля level, но для level потребуется преобразование из значения Nextcloud в значение Google LogEntry: