Cлучилась проблема у нашего клиента. CRM на 700 пользователей начала тоооормозить. Внешне все ок. Тестирование конфигурации в норме. Проверки в мониторинге тоже в норме.
Причем тормоза начинались в вечернее время и заканчивались утром. Очень удобно, чтобы не беспокоить пользователей.
Количество коннектов к mysql, службы, память, процессор, диски — все в норме. Оборудование исправно. Но скорость открытия страниц со сделками выросла в 4-5 раз.
Сначала думали, что отгрузили косячный код. На проекте работает несколько команд разработки и еще часть настроек делается через админку. Не всегда удается быстро понять, что менялось.
Когда эта гипотеза не подтвердилась, начали смотреть глубже.
Следующая гипотеза — периодические агенты. Мы нашли зависшие агенты. И как будто даже помогло их отключение, но потом проблема вернулась. Пришлось копать дальше.
Наше оборудование — 2 мощных hp-шки 10го поколения по 378Гб памяти и 72 ядра — стоит в крупном датацентре, наверно, дц №1 в России. С ними Mikrotik.
Оборудование закуплено по нашим рекомендациям через проверенного нами поставщика и очень хорошим ценам.
Датацентр не подключает оборудование напрямую в роутер. Обязательна прослойка через свитчи датацентра. Ох, сколько раз мы из-за этого сталкивались с проблемами! Особенно с iSCSI.
Заглянули в базу знаний по прошлым проблемам и нашли причину в сетевом сетке. Первое — на микротике нашли петлю из-за ошибки в конфиге. Ее поправили, но проблему это не решило.
Пошли дальше и нашли дубликаты пакетов пинг между виртуалками.
В этом проекте мы используем виртуализацию Proxmox и виртуальный сетевой адаптер с балансировкой, который состоит из двух реальных.
Это классная технология позволяет резервировать сеть и использовать сразу пару сетевых портов. Так мы получаем x2 к скорости сети. И в случае отказа одного из портов сеть не оборвется. Второй продолжит работать, выдавая половину скорости.
Оказалось, что эта прекрасная технология перестала стабильно работать.
Мы нашли это опытным путем. Отключаем один сетевой адаптер — сеть стабильно работает. Включаем обратно — опять потери. Когда поняли причину, поменяли настройки виртуального сетевого адаптера.
Все выгоды технологии остались, и стабильная работа восстановилась.
Думаю, что на стороне дц проводились какие-то работы на сетевом оборудовании. Они привели к нестабильной работе сети. Другого объяснения у нас нет.
В финале, как обычно делаем после аварий, довешали в мониторинг новых проверок, которые покажут проблему с сетью — поиск дубликатов и потерь пинга.
7 дней работает стабильно🚀.
Подписаться на новые истории
В нашей рассылке IT истории для предпринимателей, руководителей и владельцев и тех, кто собирается ими стать.
