⚠️

Уважаемые клиенты! Наблюдается снижение скорости работы Личного кабинета и ПУ vmmanager. Это связано с тем, что бекенд расположен в Германии, а фронтенд — в Польше. Возникла авария на трассе между Германией и Польшей, по этой причине трафик между этими локациями идет через обходной путь с более низкой скоростью. При этом на работу самих серверов это не влияет. Ожидаемое время нормализации — до одного часа с момента этого поста.

~~~~~~~~~~~~~~~~~~~~

Dear customers! There is a slowdown in the performance of the Personal Account and the vmmanager control panel. This is because the backend is located in Germany and the frontend in Poland. An accident has occurred on the route between Germany and Poland, and consequently, traffic between these locations is being redirected via a detour with lower speed. This does not impact the servers' own operation. The expected time for restoration is up to one hour from the time of this announcement.

H2.NEXUS 💰

🛠 Changelog

Уважаемые клиенты! С сегодняшнего дня на всех серверах исходящие почтовые порты (25, 465, 587) по умолчанию заблокированы. Это сделано для сохранения чистоты и доступности подсетей. Для разблокировки портов (только в случае реальной необходимости) необходимо создать обращение в техническую поддержку в личном кабинете, указав конкретный сервер и сценарий использования.

~~~~~~~~~~~~~~~~~~~~

Dear customers! Starting today, outbound mail ports (25, 465, 587) are blocked by default on all servers, in order to ensure the clean and availability of our subnets. To unblock them (only if you actually use them), you need to submit a request to technical support in your personal account, specifying the specific server and usage profile.

H2.NEXUS 💰

⚠️ Connectivity issue

Уважаемые клиенты! В локации Хельсинки, Финляндия, возникли проблемы с сетевым ядром, в результате чего есть проблема с доступностью серверов. Проблема на стороне дата-центра, вызвана проблемами с электропитанием. Однако точные причины и сроки устранения пока неизвестны. Мы обновим это сообщение, как только появится дополнительная информация.

UPDATE:
Удалось понять, что дело не в электричестве, так как все серверы (ноды) работают, как и ВМ, но на них нет сети по причине выхода из строя центрального роутера. Он не подаёт признаков жизни, что крайне маловероятно, учитывая, что это современный Juniper с дублированием почти всех систем.

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

UPDATE2: Сроки восстановления.
С 10 утра на работу приходит весь состав ДЦ, который может уже реально что-то решить.
Начиная с 10 (UTC+3) утра появляются два варианта развития событий:
1. Получается запустить текущий роутер, если будет уверенность что он продолжит работу стабильно, то работаем так.
2. Текущий роутер запустить не получается. Значит его нужно менять, а менять нужно сразу на более интересный, который уже есть в ДЦ. Адаптация конфигурации под новый роутер займет до часа.
Итого, можно предположить, что первый вариант с 10 (UTC+3) часов утра это плюс 1-2 часа, второй плюс 2-3 часа (от 10).

UPDATE3:
Начали замену роутера.

UPDATE4:
Заменен, восстанавливаем конфигурацию. В течении часа восстановим работу.

UPDATE5:
Запустились, серверы доступны.

~~~~~~~~~~~~~~~~~~~~

Dear clients! At the Helsinki, Finland location, issues have arisen with the network core, resulting in server availability problems. The issue is on the data center's side, caused by power supply problems. However, the exact cause and resolution timeframe are not yet known. We will update this message as soon as we have more information.

UPDATE:
We managed to figure out that the issue is not with the power supply, since all the servers (nodes) are running, as well as the virtual machines, but they have no network connectivity due to the central router having failed. It shows no signs of life, which is extremely unlikely, considering that it is a modern Juniper router with redundancy of almost all systems.

It is not possible to perform more detailed diagnostics or a replacement by the data center's night shift, even though a spare router is already available on-site. Therefore, the recovery timeline is going to be unpleasant.

UPDATE2: Service recovery time
Starting from 10:00 AM (UTC+3), the full data center team will be on site and able to take concrete action.
From 10:00 AM (UTC+3), there are two possible scenarios:
1. The current router can be started successfully. If we are confident that it will continue operating stably, we will keep using it. In this case, the estimated restoration time is 1–2 hours after 10:00 AM (UTC+3).
2. The current router cannot be started.
In this case, it will need to be replaced immediately with a more capable router that is already available in the data center. Adapting the configuration for the new router may take up to one hour. In this case, the estimated restoration time is 2–3 hours after 10:00 AM (UTC+3).
Overall, restoration can be expected within approximately 1–3 hours after 10:00 AM (UTC+3), depending on which scenario applies.

UPDATE3:
The router replacement has begun.

UPDATE4:
Replaced, we are restoring the configuration. We will have it back up and running within an hour.

UPDATE5:
New router working, the servers are online.

H2.NEXUS 💰

Как все было.

В 22:33 (UTC+0) получили алерты: головной роутер в Хельсинки упал, а с ним всё, что за ним было в локации. Подключились сразу же. Подключились к серверам по IPMI в обход нашей сети — увидели, что порты в сторону ядра лежат.

Дальше классика: попросили ЦОД подключить консольный кабель к роутеру. Бесполезно. Роутер выдавал один символ раз в 10–20 секунд и всё — ни реакции, ни процесса загрузки. Перепробовали ещё 4 консольных кабеля, ребутили разными способами, подключали других инженеров — тот же результат. Роутер совсем умер, и без каких-либо предвестников. Даже инженеры ЦОД, которые обслуживают сотни таких железок годами, были в шоке, но факт остался фактом.

К 01:00 (UTC+0) стало ясно: по сути, единственный выход — полная замена роутера на новый. К счастью, он уже был под рукой — мы как раз планировали апгрейд локации. Вторая беда: ночная смена таких работ самостоятельно не делает, так что оставалось только ждать прихода дневной смены ЦОД, которая начинается с 07:00 (UTC+0). Когда заступили, в течение часа заменили и переподключили роутер, ещё около часа ушло на перенос конфигурации и перезапуск отдельных систем — после этого сервис был восстановлен.

Q: Что сделаете, чтобы такое больше не повторилось?
A: Мигрируем Juniper на помойку. Переход на двойное ядро.

Q: Могло быть лучше?
A: Да, случись это днём — замена заняла бы не больше часа.

Q: Будет ли компенсация за простой?
A: Да. На все услуги локации добавим до 5 дополнительных дней аренды. Автоматически, в поддержку писать не надо.

~~~~~~~~~~~~~~~~~~~~

How it was.

At 22:33 (UTC+0), we received alerts: the head router in Helsinki went down, and with it, everything behind it in the location. We connected immediately. We connected to the servers via IPMI, bypassing our network, and saw that the ports towards the core were down.

Then the classic: we asked the DC to connect a console cable to the router. Useless. The router was outputting one character every 10–20 seconds and that was it — no reaction, no boot process. We tried 4 more console cables, rebooted it in different ways, involved other engineers — same result. The router completely died, without any warning signs. Even the DC engineers, who have been servicing hundreds of such pieces of hardware for years, were shocked, but the fact remained the fact.

By 01:00 (UTC+0), it became clear: basically, the only way out was a full replacement of the router with a new one. Luckily, it was already at hand — we were actually planning an upgrade of the location. The second problem: the night shift does not do such work on its own, so all that was left was to wait for the DC day shift to arrive, which starts at 07:00 (UTC+0). Once they came on shift, they replaced and reconnected the router within an hour, and about another hour was spent transferring the configuration and restarting some systems — after that, service was restored.

Q: What will you do so this does not happen again?
A: Migrating Juniper to the trash. Moving to a dual-core setup.

Q: Could it have been better?
A: Yes, if it had happened during the day — the replacement would have taken no more than an hour.

Q: Will there be compensation for the downtime?
A: Yes. We will add up to 5 additional rental days to all services in the location. Automatically, no need to write to support.

H2.NEXUS 💰

🛠 Changelog

Запущен обновлённый Looking Glass.
Теперь есть одновременная проверка со всех локаций и speedtest.
🔗 https://h2.nexus/ru/looking-glass/

~~~~~~~~~~~~~~~~~~~~

The updated Looking Glass is now live.
It now supports simultaneous testing from all locations, as well as a built-in speedtest.
🔗 https://h2.nexus/looking-glass/

H2.NEXUS 💰