К нам обратился клиент из ритейл-сегмента. Более 300 пользователей ежедневно работали в тяжелой нетиповой конфигурации 1С:ERP. База данных весила около 500 ГБ, и система начала критически тормозить: блокировки при проведении документов достигали 2-3 минут.
Проблема
Клиент был уверен, что проблема в нехватке ресурсов, и уже планировал закупку новых серверов на несколько миллионов рублей.
Аудит и выявление узких мест
Мы установили систему мониторинга (Zabbix + скрипты технологического журнала 1С) и сняли метрики. Выяснилось:
Когда бизнес работает 24/7, простой базы данных недопустим. В этом гайде мы покажем архитектуру отказоустойчивого (High Availability) кластера PostgreSQL 16, которую мы используем в production для наших Enterprise-клиентов.
Архитектура
Наш стек:
PostgreSQL 16: Сама СУБД.
Patroni: Шаблонный инструмент для управления HA PostgreSQL, разработанный Zalando.
etcd: Распределенное хранилище ключ-значение для хранения состояния кластера (DCS).
HAProxy: Балансировщик нагрузки для перенаправления трафика на мастер-узел.
Keepalived (Опционально): Для обеспечения отказоустойчивости самого HAProxy через VIP (Virtual IP).
Пошаговая настройка
(В этой статье должен быть подробный технический текст с конфигами patroni.yml, командами установки etcd и настройками haproxy.cfg. Это демонстрирует вашу глубокую экспертизу.)
РЕД Виртуализация vs zVirt: битва титанов импортозамещения
С уходом VMware российские Enterprise-компании массово мигрируют на отечественные решения. В основе большинства из них лежат KVM и oVirt, но каждая компания-разработчик дорабатывает экосистему под себя. Сегодня мы сравним двух лидеров рынка: РЕД Виртуализацию и zVirt.
Критерии сравнения
1. Архитектура и происхождение
Обе системы являются наследниками oVirt (Enterprise-версия KVM от Red Hat). Это означает поддержку кластеров высокой доступности (HA), живую миграцию (Live Migration) и продвинутые сетевые настройки.
В этом кейсе я хочу рассказать, как мы взяли тяжелое legacy-приложение и перенесли его в современную облачную инфраструктуру.
🎯 Задача
Клиент обратился с проблемой: деплой новых фич занимал несколько часов, сервера регулярно падали от нагрузки, а разработчики боялись вносить изменения в код.
🛠 Что было сделано:
Контейнеризация: Написал многоступенчатые Dockerfile для упаковки приложения.
Оркестрация: Развернул кластер Kubernetes (K8s) и написал Helm-чарты.
CI/CD: Настроил пайплайн в GitLab. Теперь при пуше в ветку main автоматически запускаются тесты, собирается образ и раскатывается в production без даунтайма (Zero-Downtime Deployment).
Мониторинг: Прикрутил Prometheus и Grafana для отслеживания метрик.
📈 Результат
Время деплоя сократилось с 4 часов до 10 минут.
Инфраструктура автоматически масштабируется при наплыве трафика.
Аптайм приложения вырос до 99.99%.
# Пример куска нашего пайплайна:deploy_production:
stage: deployimage: dtzar/helm-kubectlscript:
- helm upgrade --install my-app ./helm-chart -f values.prod.yamlonly:
- main