Системное администрирование

С удовольствием представляем очередную версию нашей системы 3CX v16 Beta 1. Финальный релиз не за горами! стали еще ближе к выпуску финального релиза. А сейчас позвольте представить новые возможности, улучшения и поддержку новой платформы, появившиеся в Beta 1.

Работа на платформе Raspberry Pi

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

Но мы сделали это! 3CX v16 теперь работает на устройствах размером с мыльницу — Raspberry Pi 3B+. Мы подготовили руководство по установке v16 на Raspberry Pi, которое приведено ниже. Устанавливайте и пользуйтесь бесплатно!

Несмотря на то, что процесс миграции с MS Exchange на Zimbra при помощи ZCS Migration Wizard довольно прост и очень быстро выполняется, он подойдет далеко не каждому предприятию. Не каждая компания может позволить себе броситься в омут с головой, в одночасье сменив один из главных рабочих инструментов на другой. В силу различных факторов, будь то высокая численность сотрудников или их низкая техническая грамотность, многие предприятия осуществляют переход с Exchange на Zimbra постепенно. В связи с этим у ИТ-менеджеров таких предприятий возникает необходимость поддерживать работу сразу двух систем электронной почты на одном и том же домене, и сейчас мы расскажем о том, как этого добиться на примере предприятия, мигрирующего с Exchange на Zimbra.

Всем привет!

В этой статье мы расскажем о том, как мы автоматизировали задачу по расширению дискового пространства на одном из наших серверов. А чего сложного в такой простой задаче, что пришлось ее автоматизировать — спросите вы? Ничего, если вы не используете каскадно-объединённое монтирование. Чувствую, вопросов стало больше!? Ну тогда поехали под кат.

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

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

Выпущенный в ноябре 2018 года AresDB представляет собой инструмент анализа в реальном времени с открытым исходным кодом. Он использует нетрадиционный источник питания, графические процессоры (GPU), что позволяет увеличивать масштаб анализа. Технология GPU, перспективный инструмент анализа в реальном времени, за последние годы значительно продвинулась, что делает ее идеальной для параллельных вычисления в реальном времени и обработки данных.

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

Чем отличается от подобных материалов?

• Реализация на чистом OpenWrt
• Использование WireGuard
• Конфигурация роутера организуется с помощью конфигов OpenWrt, а не кучей в одном скрипте
• Предусмотрены ситуации при рестарте сети и перезагрузке
• Потребляет мало ресурсов роутера: заблокированные подсети содержатся в iptables, а не в таблицах маршрутизации. Что позволяет развернуть это дело даже на слабых устройствах
• Автоматизация конфигурации с помощью Ansible (не требуется python на роутере)

Прим. перев.: Минувшей ночью Aleksa Sarai, старший инженер по контейнерам из SUSE Linux, сообщил в почтовой рассылке oss-sec о критической уязвимости в безопасности runc/LXC, которая позволяет злоумышленнику, имеющему доступ в изолированный контейнер, получить привилегии root на хостовой системе. Поскольку проблема выявлена в эталонной реализации исполняемой среды для контейнеров — runc, — она затрагивает многочисленные контейнерные системы включая Docker/Moby, Podman, cri-o (и собственно Kubernetes). Ниже представлены подробности в виде перевода сообщения инженера в почтовую рассылку.


Я являюсь одним из мейнтейнеров runc (нижележащей среды исполнения контейнеров, используемой в Docker, cri-o, containerd, Kubernetes и т.п.). Недавно стало известно об уязвимости, которую мы проверили и пропатчили.

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

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

Недоверие к результатам было вызвано многими факторами, но основными из них для меня стали следующие: параметров запуска тестов не было, количество итераций не озвучено, как выбирались машины не озвучено, подробной конфигурации тоже не было. Сомнительно, в общем.
В целом, я пользуюсь в основном Google Cloud и AWS (в сумме уже с десяток лет опыта по ним набежало) и с отечественными облачными провайдерам особо не работаю, но, по стечению обстоятельств, у меня есть активные аккаунты в Selectel, MCS, Я.Облаке и, после этого теста, еще и в Azure.

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

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

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

Интересующихся прошу под кат.

Начальные параметры:

1. Головной офис предприятия с двумя пограничными прокси Kerio Control v.9.2.9 build 3171 (за Kerio расположен свич Cisco 3550, определяющий конфигурацию локальной сети офиса).
2. На каждом Kerio организовано по два канала с балансировкой нагрузки до ISP (на схеме — ISP #1 и ISP #2) со статичными белыми IP.
3. Со стороны удалённого офиса установлен MikroTik 951G-2HnD (OS v.6.43.11).
4. На MikroTik приходят два ISP (на схеме — ISP #3 и ISP #4).

На момент написания статьи и в головном и в удалённом офисе соединение с провайдерами было по витой паре.

Список задач:

1. Организовать IPSec VPN-соединение между MikroTik и Kerio Control, где инициатором будет выступать MikroTik.
2. Обеспечить отказоустойчивость VPN-соединения, т.е. кроме того, что MikroTik должен отслеживать работоспособность своих ISP(статья здесь), он также должен мониторить доступность каждого сервера Kerio и определять, доступ по какому каналу (через какого ISP со стороны Kerio) будет производиться подключение.
3. Обеспечить возможность изменения адреса сети, с которым MikroTik подключается к Kerio. Это обусловлено тем, что в головном офисе «на границе» стоят Kerio, а не маршрутизатор.

1. С чего начать

С чего начинается резервное копирование? Планирование. При резервировании любой системы, необходимо составить план резервного копирования: что именно, как часто, как долго хранить, хватит ли свободного пространства? Из ответов на эти вопросы вытекает ответ на главный вопрос – чем бэкапить?

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

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

У Zimbra есть инструмент zmmailbox. И, при ближайшем рассмотрении его функционала, я понял, что его мне будет более, чем достаточно. Он умеет резервировать и восстанавливать ящики даже на живой системе. И мне понравилась возможность делать бэкапы критичных почтовых ящиков отдельно от бэкапа всей системы. Таким образом пространство, занимаемое резервными копиями, будет ограничено размером заархивированных почтовых ящиков, помноженным на количество дней «глубины бэкапа», а не объемом всей системы, помноженной на то же количество дней. К тому же с бэкапа всей системы, в случае с Zimbra, крайне сложно восстановиться. Гораздо проще скопировать виртуальную машину с помощью Veeam или средств управления виртуальной средой (Hyper-V, ESXI, вписать нужное) сразу после настройки системы, и положить «на полочку», чтобы в критичный момент можно было быстро развернуть почти ничего не весящую ВМ и залить в нее бэкапы ящиков. По-моему, это наименее затратный во всех отношениях сценарий.

Всем привет! В этой статье я хочу упорядочить информацию и поделиться опытом создания и использования внутреннего кластера Kubernetes.

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

0. Вступление

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