Pull to refresh

Comments 30

UFO just landed and posted this here

Хабр тоже долго жил в виде кэшей nginx. Лайфхак: потереть сессионные куки.

UFO just landed and posted this here
Либо у вас неторопливые инженеры, либо банальная экономия на резервировании оборудованиях сыграла с вами злую шутку.

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

На КДПВ подорожник не той стороной приложен. Надо было сразу правильно прикладывать — проблем бы не было.
Вообще без разницы какой стороной его прикладывать, главное пожамкать чтобы сок давал.

Спасибо за прояснение ситуации. Фиг я ещё когда-нибудь возьмусь за это неблагодарное дело по освещению деталей произошедшего вместо официального представителя.

Фиг я ещё когда-нибудь возьмусь за это неблагодарное дело по освещению деталей произошедшего

А я вот хотел поблагодарить за чудесную детализированную статью, потому что в тот вечер реально было трудно понять, что происходит в этой запутанной ситуации.
Но потом увидел вот это, и все стало на свои места
image

Так здорово, что есть такие статьи, в которых можно узнать нечто новое, да еще и с деталями. А на минусы не обращайте внимания, это все хейтеры.
03.07.2019, 17:27
Восстановлена ограниченная работоспособность Хабра.
А вот этот пункт совсем непонятен. Какую педаль нажали? Куда рулили?

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

однако часть сервисов оказалась неработоспособной, так как был нарушен механизм разрешения имён на name-серверах (dns).

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


Hosts автоматически обновлять на всех хостах достаточно просто, зато лишним такая мера не будет.

Но, да, использовать IP-адреса и отключить в настройках сервиса ресолвинг имен — и надежнее, и «дешевле» для приложения, не будет затраты времени на любой ресолвинг.
Всё отлично, только про учения не понял. Или это юмор?
UFO just landed and posted this here

Вполне себе отработка кейса, когда по чьей-то воле вдруг теряется связность с частью используемых api и иных ресурсов. Или ломается в том или ином виде часть DNS (или DNSSSec для всей .com-зоны).

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

Dual stack с IPv6 пригодился бы. У моего провайдера пару недель назад были похожие по симптомам проблемы (не работал NAT или другая проблема с IP маршрутизацией). Зато ресурсы с IPv6 были доступны.

IPv6 активно пилим.

Тоже за Куратора будете "прятать"?

У нас отделена сеть автономной системы от сети публичных сервисов. Это вообще два не взаимосвязанных сегмента. IPv6 на публичных сервисах появится тогда, когда появится у Qrator, на backbone у нас уже есть IPv6.

То что иконки отъехали примерно в это же время в мобильном FF, может быть как-то связано?

Они, кстати, до сих пор не пашут.

UFO just landed and posted this here
Проблема несколько усугубилась тем, что данное оборудование также терминировало входящие подключения клиентских VPN сотрудников, удалённые работы по восстановлению стало проводить сложнее.

Интересно! А сколько из прочитавших этот абзац осознали, что и у них VPN и NAT повязаны, я уж молчу про тех кто «ходит» по железкам из дома через рабочий ПК.

Теперь ждём статью по следам этого postmortem о том как вы разнесли NAT на разное оборудование, с резервированием и/или распределением нагрузки. Плюсы, минусы, подводные камни…

Мы сейчас разворачиваем технически отделённую oob-сеть. С ipsec и bgp через lte-модемы. Скорее всего будет пост.

Извините, но сетевиков ваших (если они у вас есть) гнать нужно ссаными тряпками за такое.
И за то, что служебный VPN сидит рядом с продуктивом (вероятно на ASA), и за NAT (ЗАЧЕМ?!), и за то, что нет резервирования…

Если всех гнать ссаными тряпками — тряпок не хватит. Или тех, кого ими гнать. Как бы то ни было, не самое конструктивное решение. Сказываются затянувшиеся переделки опорной сети, на одном из этапов которых "временно" VPN сел на ASA (а не за неё). Но нет ничего более постоянного, чем временное, это уже недогляд и неправильная приоритезация задач.

Не, сам VPN на ASA — это норм. Anyconnect — очень удобная и гибкая штука.
Тут дело в другом — как вообще можно совмещать на одном железе oob и продуктив?! Даже временно. Как можно не резервировать критичные компоненты? Переезд переездом, но это не повод снижать надёжность системы.
Не хватает полноценного хаба с постмортемами, спасибо, полезная информация.
Sign up to leave a comment.