» NAT и публикация сервисов с учётом virtual hosts

Цитата:

Не, у меня есть огромное желание поиметьсся с SAN. Технология запретительно дорогая,

Нихрена она уже не дорогая ))
Модельки iSCSI инфраструктуры можно собрать и пощупать и на 100Мбит, реально в продуктиве пашет на гигабитном езернете (разве что не рекомендуется связываться с марвеллами-реалтеками и под.: только интел.) Свичи нужны да, гигабитные - но строго предпочительны L2 (уже имеющиеся L3 фичи рекомендуется отключать).

И сразу получаешь выигрыш: никакой проприетарщины с сопутстствующим ей геморроем.
Но и теряешь... сомнительное удовольствие (затрахавшись и отчаявшись разобраться) докупить дополнительно платную управлялку от вендора стораджа.

LevT
Цитата:

Модельки iSCSI инфраструктуры можно собрать и пощупать и на 100Мбит

у? Я что-то упустил? Или вы мне о FCoE говорите? Нашедшего воплощение в iSCSI?

FCoE как раз идёт в качестве бонуса только к 10GbE адаптерам (они умеют прикидываться FC - если ось умеет инициализировать эту их функцию). Мне неизвестны гигабитки, где бы FCoE был.

А вот iSCSI - он over TCP/IP. Ничего кроме сетевой карты для него не надо.

Зачем тогда специализированные "iSCSI HBA"? А для того, чтобы уже биосу сообщить о доступных через них лунах и иметь возможность с них загрузить систему. Если нет такой задачи, то от них только лишние хлопоты: они не столь гибкие и более капризные, чем обычные сетевушки.

Такс, что-то мы ушли общаться на тему поднятую мной в другой ветке) Перемещаемся обратно туды...

Alukardd
Офисный народ жалуется на балансировщик Zentyal-а: отваливаются не только файлопомойки и вебморда почтового хостера, но и половина внешних сервисов типа mail.ru.

Какой костыль ты бы посоветовал применить? Учитывая, что я тороплюсь свалить в отпуск, и от Zentyal в качестве шлюза-балансировщика сейчас отказываться не могу.

Alukardd

1. Моя интуитивная идея разделить шлюз DNAT (gw) и балансировшик каналов (pgw), оказывается, раньше меня осенила некоторых продвинутых линуксоидов

http://xgu.ru/wiki/Default_gateway

http://vladimir-stupin.blogspot.com/2008/12/dnat-policy-based-routing.html



2. Сплит ДНС вещь хорошая, но если авторитетный провайдер публичной DNS-зоны не даёт делать её трансфер, то приходится зону воспроизводить внутри конторы вручную, что вызывает законное раздражение.

ДНС маскарадинг должен выручать. Типа прозрачный DNS-прокси на роутере, который подменяет результаты некоторых запросов (перечисленных в его конфиге).

Вот только вопрос: где лучше маскарадинг разместить, на gw или на pgw? (С учётом той перспективы, что со временем внутри конторы появятся авторитетные NS для некоторых публичных зон).

LevT
NS можно разместить много где: на шлюзе; в локалке (DNAT на него делать); в DMZ.
Не понял я что-то твой крен в сторону про DNS-прокси... Split DNS и так предполагает настройку одной зоны дважды, так что я ни каких проблем не вижу.

LevT
Цитата:

2. Сплит ДНС вещь хорошая, но если авторитетный провайдер публичной DNS-зоны не даёт делать её трансфер,  то приходится зону воспроизводить внутри конторы вручную, что вызывает законное раздражение.

Ваши отточенные формулировки всегда приводят меня в восхищение, но в данный момент по-моему вы просто не понимаете, о чем говорите.
Split DNS - это просто способ на своем DNS сервере выдавать результат в зависимости от айпи запрашивающих клиентов. К трансферу чужих зон он никакого отношения не имеет.

vlary
Цитата:

Ваши отточенные формулировки всегда приводят меня в восхищение

восхищение не совсем то слово, но сутью согласен

Да Ваши ответы обычно чёткие и редко после них остаются вопросы, только если уж совсем глубоко не копать, чем я обычно болею...
Мой методом объяснения и понимания ближе всего к методу "на пальцах".

vlary
Мне кажется, что возможность вносить изменения в единственном месте большая ценность. Поэтому от сплит днс толку для меня лично мало, если надо воспроизводить зону целиком.

Удобнее сделать лишний раз трансфер изменённой зоны и поправить нужные записи по списку. Но например бывший dyndns (который теперь dyn.com) такого не позволяет.


Alukardd
Скажи, а ты принципиальный противник dns маскарадинга (почему?), или просто не копал его глубоко - и потому не берёшься его советовать и дизайнить что-то на его основе?

LevT
1 - глубоко не копал.
2 - не стоит использовать ни какие технологии перехвата, если в этом нет необходимости.
3 - единственный бонус — не надо перенастраивать клиентские машины, хотя в 90% случаев, они и так настроены на внутрекорпоративный NS.

Зону воспроизвести нужно единожды, а потом мелкие настройки только докидывать. Если много доменов и часто что-то меняется, можно это дело автоматизировать (dig axfr и вперёд парсить вывод и создавать новый конфиг), но стоит ли выделываться?

И как я такую тему пропустил ?

а как pppoe к провайдеру на разных шлюзах резервировать ?
сам шлюз по VRRP, а коннект к провайдеру ?

Dimsoft
Эм...
Цитата:

И как я такую тему пропустил

и зачем только ты её нашёл? Вопросы явно не о том.
Если надобно что бы коннект к провайдеру поднимался на втором припадении первого, то есть нужно не просто подмена ip, но и выполнение некого скрипта.
В ucarp, например, это называется upscript.

Цитата:

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

Alukardd
IMHO
как то бы таблицы NAT клиентов между двумя роутерами синхронизировать (между ними 1Gb к провайдеру только 100мб, думаю можно по скорости) и при падении роутера второй поднимал бы с тогоже mac адреса с тем же логином/паролем pppoу сессию и фиксированным белым IP и прозрачно для клиентов и серверов в интернете продолжал.
Или я слишком размечтался ? А без велосипеда как эту задачу решают ? Без AS ?