Действительно ли глобальные балансировщики так часто падают, чтобы нужно было изобретать свой велосипед?
Чем, например, плохо решение поставить TTL 5 минут, и в случае проблем - перевести DNS-записи на статику? Или как раз эту проблему и пытаетесь решить наперёд?
Как один из вариантов простого решения - использования службы типа Azure Traffic Manager - он делает именно DNS-резолв в нужный датацентр в зависимости от заданных параметров (в т.ч. доступности ДЦ). Сам же HTTP трафик будет идти напрямую от клиента в датацентр.
Ну и наконец если и этот вариант не подходит - можно достаточно просто соорудить эту конструкцию с помощью NS-серверов, например: www.sportmaster.ru -> (CNAME) www.dc-selector.sportmaster.ru (это отдельный под-домен) Зона dc-selector должна иметь 2 NS: по одному в каждом DC. Соответственно, NS для этой зоны будет отдавать только IP своего DC: www.dc-selector.sportmaster.ru (из DC1) -> x.x.1.1 (IP DC1) www.dc-selector.sportmaster.ru (из DC2) -> x.x.2.1 (IP DC2) Если DC1 недоступен, то ответит только NS из DC2, и отрезолвит в правильный IP Таким образом выбор DC будет осуществляться рекурсивным резолвером, а клиент будет получать готовый результат.
Единственное "но" - это опять изобретение велосипеда - того же Traffic Manager.
Да, именно https:// в RewriteRule мне и не хватало :)
Что же касается первой части моего ответа. Скорее всего валидаторы проверяют не поведение сайта, а сам код конфигов? Тогда представьте, что в изначальной форме, где проверка на HTTPS идёт второй:
Если сайт идёт с www, то сработает первое условие, и уже не важно, был ли сайт с HTTPS или без. Условие HTTP(s) можно не проверять, т.к. действие (RewriteRule) всё равно запускать. Именно это и называется ленивым вычислением. Я бы сказал, что это ошибка проверяющих, а не конфига.
Ошибка проверки не должна появляться, если проверяется не текст конфига, а поведение сайта снаружи, т.к. в данном случае правило сработает, а почему - для валидатора не видно.
Скорее всего дело в том, что здесь используются "ленивые вычисления" - т.е. до если первое условие выполнено, то второе вычислять и не нужно (там ведь OR).
Об этом сказано в документации, но очень завуалированно: It has to be kept in mind that conditions follow a short circuit logic in the case of the 'ornext|OR' flag so that certain conditions might not be evaluated at all.
Поэтому в данном случае от перемены мест результат меняется.
И еще один вопрос: в RewriteRule выше - как происходит upgrade до HTTPS? Там есть еще какая-то инструкция, что вместо http нужно отдать https, или это просто случайно пропущено, и должно быть так?
Если вначале проверять на www, то обычно редирект идёт с http на http://www, и только второй уже с http на https. Поэтому первый и не нравится чекерам. Логично сразу делать http://site → https://www.site, тогда и проверка пройдет, и один редирект сэкономится.
Один из вариантов - использование mobile device management, например, Microsoft Intune.
И пока вы не поставите intune, он не проверит вашу машину, не поставит кучу необходимого софта (антивирус, патчи и т.п.) - вы просто не сможете подключиться к корпоративной сети и нормально работать.
По факту - переставить можно, но итоговое окружение все равно будет такое же как корпоративное.
Чтобы рассчитывать на резервирование в Dual-ToR — нужно загружать каналы < чем на 50% (иначе отказ линка приведет к каскадным отказам по производительности), а это уже расход денег.
Плюс — policy-based routing чтобы отделить трафик хранилки от сетевого трафика (если я правильно понял) — это тоже дополнительные проблемы дизайна.
Решит ли добавление второго линка к хосту проблему отказоустойчивости? Кажется, только усложнит жизнь.
Интересно, заставляет задуматься. Ho есть пара комментариев.
Всё это работает прекрасно, если и отправитель, и получатель находятся в дата центре (контролируемой среде). Тогда отправляющий хост может исправить flow label.
Как быть, если отправитель снаружи? Хост, делающий инкапсуляцию, не всегда (почти никогда) не будет видеть обратного потока, и не сможет узнать о потеряx.
И относительно балансировки по flow label на сетях оператора. В целом, все документы, те же RFC 6437, 6438 говорят о том, что маршрутизаторы должны принимать во внимание метку при балансировке. Чего нe стоит ожидать — тaк это замены flow label в середине потока.
Так что, с одной стороны это технология (замены flowlabel) прекрасна внутри DC, с другой стороны не стоит ожидать, что она решит проблемы с внешними подключениями. Скорее наоборот
Видать, пропустил момент, когда atlas стало возможно делать сотовым.
А есть ли мануал, как его залить на поддерживаемое железо? На ту же малинку. Не хочется дома делать виртуальную машину, а вот мелкую железку бы поставил.
Решал несколько подобных кейсов при подключении ASA к Azure. Там логи норм ))
* Одна из проблем — когда на одной из сторон (ASA) включен PFS, на другой (Azure) — нет.
Тогда во время re-key, если его начинает Azure, то по странной причине ASA его принимает, но трафик ходить перестает, когда истекают старые ключи. Решение — выключить PFS. Или включить. На обеих сторонах.
* Можно подправить время lifetime — сделать его меньше на стороне ASA. Тогда этот процесс всегда будет начинаться со стороны Асы. Но это криво, т.к. не решает проблему, а просто делает её незаметной.
* Часто возникают проблемы с трафик селекторами, как и говорили выше. Они должны быть одинаковыми. В ином случае проблема будет сильно плавающей — в зависимости от того, какая сторона будет начинать re-key. А это будет зависеть от типа трафика.
Если ASA с новой прошивкой (>9.8), лучше использовать VTI и 0.0.0.0/0 трафик-селекторы с обеих сторон (а разрешать/запрещать через маршруты/ACL). Так, по крайней мере, одной проблемой меньше.
Важно, что электричество берут с возобновляемых источникв энергии — ветряков, энергии волн и т.п. Поэтому с точки зрения именно тепла эффект на планете будет нулевым. Сколько взяли энергии у ветра, столько и отдали воде.
Другое дело что да, локальное тепло вокруг — это изменение микроклимата вокруг этой бочки. Ну такое же, как вокруг речки, текущей из любой ТЭЦ.
Интересное видео про время и таймзоны. Очевидно, и Вы, и они попали как раз на все эти обычные для времени штуки :)
The Problem with Time & Timezones — Computerphile youtu.be/-5wpm-gesOY
Действительно ли глобальные балансировщики так часто падают, чтобы нужно было изобретать свой велосипед?
Чем, например, плохо решение поставить TTL 5 минут, и в случае проблем - перевести DNS-записи на статику? Или как раз эту проблему и пытаетесь решить наперёд?
Как один из вариантов простого решения - использования службы типа Azure Traffic Manager - он делает именно DNS-резолв в нужный датацентр в зависимости от заданных параметров (в т.ч. доступности ДЦ). Сам же HTTP трафик будет идти напрямую от клиента в датацентр.
Ну и наконец если и этот вариант не подходит - можно достаточно просто соорудить эту конструкцию с помощью NS-серверов, например:
www.sportmaster.ru -> (CNAME) www.dc-selector.sportmaster.ru (это отдельный под-домен)
Зона dc-selector должна иметь 2 NS: по одному в каждом DC.
Соответственно, NS для этой зоны будет отдавать только IP своего DC:
www.dc-selector.sportmaster.ru (из DC1) -> x.x.1.1 (IP DC1)
www.dc-selector.sportmaster.ru (из DC2) -> x.x.2.1 (IP DC2)
Если DC1 недоступен, то ответит только NS из DC2, и отрезолвит в правильный IP
Таким образом выбор DC будет осуществляться рекурсивным резолвером, а клиент будет получать готовый результат.
Единственное "но" - это опять изобретение велосипеда - того же Traffic Manager.
Да, именно https:// в RewriteRule мне и не хватало :)
Что же касается первой части моего ответа. Скорее всего валидаторы проверяют не поведение сайта, а сам код конфигов? Тогда представьте, что в изначальной форме, где проверка на HTTPS идёт второй:
RewriteCond %{HTTP_HOST} ^www\. [OR]RewriteCond %{HTTPS} !=on
Если сайт идёт с www, то сработает первое условие, и уже не важно, был ли сайт с HTTPS или без. Условие HTTP(s) можно не проверять, т.к. действие (RewriteRule) всё равно запускать. Именно это и называется ленивым вычислением.
Я бы сказал, что это ошибка проверяющих, а не конфига.
http://www -> fail
http://ifap -> pass
https://www -> pass
https://ifap -> pass
Ошибка проверки не должна появляться, если проверяется не текст конфига, а поведение сайта снаружи, т.к. в данном случае правило сработает, а почему - для валидатора не видно.
Скорее всего дело в том, что здесь используются "ленивые вычисления" - т.е. до если первое условие выполнено, то второе вычислять и не нужно (там ведь OR).
Об этом сказано в документации, но очень завуалированно:
It has to be kept in mind that conditions follow a short circuit logic in the case of the '
ornext|OR' flag so that certain conditions might not be evaluated at all.Поэтому в данном случае от перемены мест результат меняется.
И еще один вопрос: в RewriteRule выше - как происходит upgrade до HTTPS? Там есть еще какая-то инструкция, что вместо http нужно отдать https, или это просто случайно пропущено, и должно быть так?
RewriteRule (.*) https://ifap.ru%{REQUEST_URI} [NE,R=301]Если вначале проверять на www, то обычно редирект идёт с http на http://www, и только второй уже с http на https. Поэтому первый и не нравится чекерам. Логично сразу делать http://site → https://www.site, тогда и проверка пройдет, и один редирект сэкономится.
Один из вариантов - использование mobile device management, например, Microsoft Intune.
И пока вы не поставите intune, он не проверит вашу машину, не поставит кучу необходимого софта (антивирус, патчи и т.п.) - вы просто не сможете подключиться к корпоративной сети и нормально работать.
По факту - переставить можно, но итоговое окружение все равно будет такое же как корпоративное.
Плюс — policy-based routing чтобы отделить трафик хранилки от сетевого трафика (если я правильно понял) — это тоже дополнительные проблемы дизайна.
Решит ли добавление второго линка к хосту проблему отказоустойчивости? Кажется, только усложнит жизнь.
Как в анекдоте: "этих отмоем или новых нарожаем?" :)
Интересно, заставляет задуматься. Ho есть пара комментариев.
Всё это работает прекрасно, если и отправитель, и получатель находятся в дата центре (контролируемой среде). Тогда отправляющий хост может исправить flow label.
Как быть, если отправитель снаружи? Хост, делающий инкапсуляцию, не всегда (почти никогда) не будет видеть обратного потока, и не сможет узнать о потеряx.
И относительно балансировки по flow label на сетях оператора. В целом, все документы, те же RFC 6437, 6438 говорят о том, что маршрутизаторы должны принимать во внимание метку при балансировке. Чего нe стоит ожидать — тaк это замены flow label в середине потока.
Так что, с одной стороны это технология (замены flowlabel) прекрасна внутри DC, с другой стороны не стоит ожидать, что она решит проблемы с внешними подключениями. Скорее наоборот
Видать, пропустил момент, когда atlas стало возможно делать сотовым.
А есть ли мануал, как его залить на поддерживаемое железо? На ту же малинку. Не хочется дома делать виртуальную машину, а вот мелкую железку бы поставил.
* Одна из проблем — когда на одной из сторон (ASA) включен PFS, на другой (Azure) — нет.
Тогда во время re-key, если его начинает Azure, то по странной причине ASA его принимает, но трафик ходить перестает, когда истекают старые ключи. Решение — выключить PFS. Или включить. На обеих сторонах.
* Можно подправить время lifetime — сделать его меньше на стороне ASA. Тогда этот процесс всегда будет начинаться со стороны Асы. Но это криво, т.к. не решает проблему, а просто делает её незаметной.
* Часто возникают проблемы с трафик селекторами, как и говорили выше. Они должны быть одинаковыми. В ином случае проблема будет сильно плавающей — в зависимости от того, какая сторона будет начинать re-key. А это будет зависеть от типа трафика.
Если ASA с новой прошивкой (>9.8), лучше использовать VTI и 0.0.0.0/0 трафик-селекторы с обеих сторон (а разрешать/запрещать через маршруты/ACL). Так, по крайней мере, одной проблемой меньше.
Другое дело что да, локальное тепло вокруг — это изменение микроклимата вокруг этой бочки. Ну такое же, как вокруг речки, текущей из любой ТЭЦ.
The Problem with Time & Timezones — Computerphile
youtu.be/-5wpm-gesOY