Доброго времени суток, aLL.Имеется 2 инет- канала по 100мбит, оба с внешними IP. В сети имеются следующие сервисы, необходимые для доступа извне а именно:
- обычный сайт на 80 порту;
- второй сайт на 443 порту (самоподписанный SSL);
- порт для VPN;
- порт для asterisk;
- возможны дополнительные сервисы в будущем, какие - пока неизвестно.На каждом из каналов шлюзом стоит pfSense. На серверах - Debian, CentOS. На данный момент все сервисы просто физически разнесены по разным каналам.
Каналы часто падают, порой, надолго, отказоустойчивость становится все важнее и важнее...
Подскажите, каким образом агрегировать эти два канала чтобы прозрачно для клиентов извне все сервисы работали? Чтобы извне все выглядело как обращение по одному конкретному имени/адресу, а дальше было агрегирование или, если какой-то канал лежит, выбор рабочего маршрута. То-есть, чтобы не было, как в случае с DNS RoundRobin - при обращении к IP, канал которого лежит, 30 сек ждем таймаута, повторный опрос DNS и идем по второму маршруту.В идеале бы агрегировать с увеличением суммарной пропускной способности (грубо говоря 100+100=~200).
Где про это можно подробнее почитать? Возможно ли сие вообще?ЗЫЖ Имеются также непристроенные cisco 2911, cisco 3825, если нужно - их можно задействовать для решения задачи.
>[оверквотинг удален]
> Подскажите, каким образом агрегировать эти два канала чтобы прозрачно для клиентов извне
> все сервисы работали? Чтобы извне все выглядело как обращение по одному
> конкретному имени/адресу, а дальше было агрегирование или, если какой-то канал лежит,
> выбор рабочего маршрута. То-есть, чтобы не было, как в случае с
> DNS RoundRobin - при обращении к IP, канал которого лежит, 30
> сек ждем таймаута, повторный опрос DNS и идем по второму маршруту.
> В идеале бы агрегировать с увеличением суммарной пропускной способности (грубо говоря 100+100=~200).
> Где про это можно подробнее почитать? Возможно ли сие вообще?
> ЗЫЖ Имеются также непристроенные cisco 2911, cisco 3825, если нужно - их
> можно задействовать для решения задачи.Имхо только получение пула IP адресов PI ("Provider Independent").
Такой пул с IPV4 вряд ли уже получите, но попробуйте получить.
>[оверквотинг удален]
>> конкретному имени/адресу, а дальше было агрегирование или, если какой-то канал лежит,
>> выбор рабочего маршрута. То-есть, чтобы не было, как в случае с
>> DNS RoundRobin - при обращении к IP, канал которого лежит, 30
>> сек ждем таймаута, повторный опрос DNS и идем по второму маршруту.
>> В идеале бы агрегировать с увеличением суммарной пропускной способности (грубо говоря 100+100=~200).
>> Где про это можно подробнее почитать? Возможно ли сие вообще?
>> ЗЫЖ Имеются также непристроенные cisco 2911, cisco 3825, если нужно - их
>> можно задействовать для решения задачи.
> Имхо только получение пула IP адресов PI ("Provider Independent").
> Такой пул с IPV4 вряд ли уже получите, но попробуйте получить.кстати на этом форуме есть баннер регистранта, который предлагает такую услугу
http://ip-as.ru/
> Имхо только получение пула IP адресов PI ("Provider Independent").
> Такой пул с IPV4 вряд ли уже получите, но попробуйте получить.Понятно, как, например, решаются подобные задачи, большое спасибо за ответ.
Не занимайтесь фигнёй, а купите VPS и держите критичные по уровню доступности сервисы на нём. Деньги это совсем небольшие.Если же это не вариант, то извратиться можно так: Поставить bind на сервере, к которому подключены оба канала. Сделать на бинде две версии зоны, разделить их с помощью view (см. match-destinations) и в каждой версии отдавать только свой IP. В результате, когда один из каналов лежит, клиенты всегда будут получать от ДНСа адрес рабочего канала.
> Не занимайтесь фигнёй, а купите VPS и держите критичные по уровню доступности
> сервисы на нём. Деньги это совсем небольшие.К сожалению не вариант и придется таки заниматься фигней. Ибо:
1. Деньги-то небольшие, но и с ними беда;
2. Госконтора и все, что связано с защитой данных и местами их хранения;
3. Объемы данных очень скоро станут очень большими;
4. Проблематичность оплаты VPS.> Если же это не вариант, то извратиться можно так: Поставить bind на
> сервере, к которому подключены оба канала. Сделать на бинде две версии
> зоны, разделить их с помощью view (см. match-destinations) и в каждой
> версии отдавать только свой IP. В результате, когда один из каналов
> лежит, клиенты всегда будут получать от ДНСа адрес рабочего канала.Так, а вот это уже интересно, спасибо большое, буду почитать...
Хотя... Кеширующие ДНСы провайдера ведь далеко не всегда будут обращаться непосредственно к моему ДНС за точным IP в данный конкретный момент времени. И клиенты в итоге могут получать именно адрес лежащего сейчас канала. А, значит, со стороны клиента, схема, в принципе, особо не отличается от того же RoundRobin.
> 2. Госконтора и все, что связано с защитой данных и местами их
> хранения;В рф тоже есть хостинговые компании, и вроде даже дешёвые имеются. Хотя их надёжность у меня вызывает сомнения, да.
> Хотя... Кеширующие ДНСы провайдера ведь далеко не всегда будут обращаться непосредственно
> к моему ДНС за точным IP в данный конкретный момент времени.Низкий TTL сведёт эту проблему к минимуму.
> И клиенты в итоге могут получать именно адрес лежащего сейчас канала.
> А, значит, со стороны клиента, схема, в принципе, особо не отличается
> от того же RoundRobin.Понятие TTL изучите ...
> Низкий TTL сведёт эту проблему к минимуму.
> Понятие TTL изучите ...Простите, но какое отношение установленный у меня TTL (скажем, 60 секунд) повлияет, например, на кэширующий ДНС провайдера какого-нибудь клиента, у которого TTL будет выше (скажем, 6000 секунд)? Клиент получит адрес от своего прова, а не от моего ДНС.
Канал часто может падать на не длительное время - 10-20 минут.
Плюс вот статья: http://www.zytrax.com/books/dns/info/minimum-ttl.html - это еще проблемы с локальными кэшами браузеров, клиентами всяких xDSL и безопасностью вообще.
>> Низкий TTL сведёт эту проблему к минимуму.
>> Понятие TTL изучите ...
> Простите, но какое отношение установленный у меня TTL (скажем, 60 секунд) повлияет,cсамое прямое, и даже наипримейшее
> например, на кэширующий ДНС провайдера какого-нибудь клиента, у которого TTL будет
> выше (скажем, 6000 секунд)? Клиент получит адрес от своего прова, а
> не от моего ДНС.днс сервер не увеличивает ттл, он его наоборот может еще порезать.
> Канал часто может падать на не длительное время - 10-20 минут.
> Плюс вот статья: http://www.zytrax.com/books/dns/info/minimum-ttl.html - это еще проблемы
> с локальными кэшами браузеров, клиентами всяких xDSL и безопасностью вообще.браузеры да, трабл на трабле - но вам в самом верху и писал товарищ что это костыльное решение.
> 2. Госконтора и все, что связано с защитой данных и местами их
> хранения;А вот тут стоп. Госконтора - это значит конкурс на поставку решения и возможно госконтракт.
ТЗ есть? Распоряжение из министерства к которому принадлежит ваша контора?
Либо вы строите нечто незаконное, либо вас используют не по назначению.
>> 2. Госконтора и все, что связано с защитой данных и местами их
>> хранения;
> А вот тут стоп. Госконтора - это значит конкурс на поставку решения
> и возможно госконтракт.
> ТЗ есть? Распоряжение из министерства к которому принадлежит ваша контора?
> Либо вы строите нечто незаконное, либо вас используют не по назначению.Мы сами себе министерство. В ДНР.
>>> 2. Госконтора и все, что связано с защитой данных и местами их
>>> хранения;
>> А вот тут стоп. Госконтора - это значит конкурс на поставку решения
>> и возможно госконтракт.
>> ТЗ есть? Распоряжение из министерства к которому принадлежит ваша контора?
>> Либо вы строите нечто незаконное, либо вас используют не по назначению.
> Мы сами себе министерство. В ДНР.Нужно у провайдеров поставить свое оборудование, те же циски...
И настроить уже на них балансировку, так что если линк от провайдера к вам будепт падать - то ваша циска на стороне провайдера будет перекидывать трафик на другого провайдера...
Возможно за такой "колокейшен" все же прийдется заплатить небольшую денюжку.. А может и просто договоритесь используя административный ресурс...
>[оверквотинг удален]
>>> и возможно госконтракт.
>>> ТЗ есть? Распоряжение из министерства к которому принадлежит ваша контора?
>>> Либо вы строите нечто незаконное, либо вас используют не по назначению.
>> Мы сами себе министерство. В ДНР.
> Нужно у провайдеров поставить свое оборудование, те же циски...
> И настроить уже на них балансировку, так что если линк от провайдера
> к вам будепт падать - то ваша циска на стороне провайдера
> будет перекидывать трафик на другого провайдера...
> Возможно за такой "колокейшен" все же прийдется заплатить небольшую денюжку.. А может
> и просто договоритесь используя административный ресурс...Но как вы вероятно понимаете, если при этом упадет сам провайдер- то такое решение не поможет, и остается только надежда на балансировку через ДНС.
>>[оверквотинг удален]
>> Нужно у провайдеров поставить свое оборудование, те же циски...
>> И настроить уже на них балансировку, так что если линк от провайдера
>> к вам будепт падать - то ваша циска на стороне провайдера
>> будет перекидывать трафик на другого провайдера...
>> Возможно за такой "колокейшен" все же прийдется заплатить небольшую денюжку.. А может
>> и просто договоритесь используя административный ресурс...
> Но как вы вероятно понимаете, если при этом упадет сам провайдер- то
> такое решение не поможет, и остается только надежда на балансировку через
> ДНС.Да, в нормальных условиях мы бы даже не отдавали свое оборудование, а порешали бы с провайдерами на их базе. А так, не факт, что сегодня завтра не прилетит какая-то гадость непосредственно к прову и - финита ля комедиа. Например, прецеденты перебивания кабельной трассы непосредственно "Ураганом" (конкретно сама "труба" вошла в кабельный канал и там застряла) или лопатой бойкими ребятами с украины при копании окопов ("Які дроти? А, ось ці - он вони, ми їх у сторонку витягнули та скрутили") - это не байка, а - реалии.
> Удачи вам ребята, и Победы!Спасибо, мы работаем над этим :)
> По хорошему вам надо взять AS Number, блок IP, и настроить BGP.
> Через любую среду что найдёте до множества аплинков которые согласны пириться
> по BGP. Оптика, витуха, телефонная лапша через модем, лазерка, УКВ или
> Wi-Fi канал - будет влиять только на лаг и трупут. Но
> надёжность будет наивысшая.Спасибо за ответ.
Да, это отличный, надежный вариант. Но - когда все норм вокруг. А так как сейчас - я же даже заявки на AS подать не смогу - "самопровозглашенные" же мы, ворох юридических проблем. И с оплатой вопрос. И все то, что я описал ниже.
>[оверквотинг удален]
>> По хорошему вам надо взять AS Number, блок IP, и настроить BGP.
>> Через любую среду что найдёте до множества аплинков которые согласны пириться
>> по BGP. Оптика, витуха, телефонная лапша через модем, лазерка, УКВ или
>> Wi-Fi канал - будет влиять только на лаг и трупут. Но
>> надёжность будет наивысшая.
> Спасибо за ответ.
> Да, это отличный, надежный вариант. Но - когда все норм вокруг. А
> так как сейчас - я же даже заявки на AS подать
> не смогу - "самопровозглашенные" же мы, ворох юридических проблем. И с
> оплатой вопрос. И все то, что я описал ниже.А зачем в ДНР доступ в Интернет? Вам ДНРнет строить нужно бы в Донбабвэ.
>>[оверквотинг удален]
> А зачем в ДНР доступ в Интернет? Вам ДНРнет строить нужно бы в Донбабвэ.Я бы тоже подумал по поводу fake-ASN и прочая ...
В реальный интернет можно сделать шлюз, который всё замаскарадит :)А насчёт домбабвэ ... это ваши визави от бессильной злобы изголяются, пусть их! :)
> Я бы тоже подумал по поводу fake-ASN и прочая ...
> В реальный интернет можно сделать шлюз, который всё замаскарадит :)Я, может, "глупый вещь скажу", но: если я возьму, скажем, VPS, на нем ставлю какой-нибудь pfSense, и через него делаю агрегирование своих каналов. К этой же VPS привязываю свое доменное имя. То-есть эта VPS-ка будет, по сути, NAT-ить все запросы клиентов на мои реальные адреса и сервисы. Получаем нечто вроде промежуточного шлюза.
Можно и не агрегирование, а - отказоустойчивость: VPS-ка следит за каналами, в случае падения одного из них - перенаправляет всех на другой.
Все-таки у хостеров VPS-ок получше моего и со связью, и со спецами - они 24/7/365 смогут с минимальным простоем обеспечить.
Со стороны моей конторы выход в инет юзерам, asterisk и прочее будет как обычно: это - по этому каналу, это - по тому...> А насчёт домбабвэ ... это ваши визави от бессильной злобы изголяются, пусть
> их! :)Да бандера им судья
> Я, может, "глупый вещь скажу", но: если я возьму, скажем, VPS, на
> нем ставлю какой-нибудь pfSense, и через него делаю агрегирование своих каналов.Не так всё просто :(
Ну то есть доступ из интернета к твоим серверам через один или другой или третий канал ты сделаешь...
А вот как наоборот - со стороны твоих сетей ... Нужен будет аналог такого же VPS, для каждой сети локальный. И мы возвращаемся к исходному вопросу :(
> Не так всё просто :(
> Ну то есть доступ из интернета к твоим серверам через один или
> другой или третий канал ты сделаешь...
> А вот как наоборот - со стороны твоих сетей ... Нужен будет
> аналог такого же VPS, для каждой сети локальный. И мы возвращаемся
> к исходному вопросу :(Да, как-то сложно все получается, не сообразил.
Пожалуй, для начала (ввиду простоты реализации) сделаю "отказоустойчивость" ДНСом, посмотрю, как оно поведет себя в реале на моих задачах. А позже, с более-менее нормализацией ситуации вокруг, буду двигаться к нормальным решениям, совместно с провайдерами, или чем-то из вышеизложенного всеми отписавшимися здесь. Главное - понятно где и куда рыть, что читать и сколько чего курить :)Всем большое спасибо за помощь.
CDN
> CDNСпасибо за ответ.
В принципе, решение, но, ИМХО, чересчур избыточное в моем случае. Впрочем, почитаю подробнее.
> Подскажите, каким образом агрегировать эти два канала чтобы прозрачно для
> клиентов извне все сервисы работали?Идете к одному из своих провайдеров, с которым легче договориться.
По каналу второго провайдера подымаете туннель "вы-пров2-пров1".
Получаете отказоустойчивость канала "пров1".
Или наоборот.Аггрегация+отказоуйстойчивость решается одними средствами,
только отказоустойчивость - другими.Например, как вариант создания отказоустойчивости, можно поднять внутренний BGP-стык с пров1 по двум каналам - прямому и туннельному. Для этого ничего не нужно кроме как поддержки вашей хотелки со стороны провайдера пров1.
В качестве туннеля может быть и проброс VLAN, если, провайдеры пров1 и пров2 захотят и смогут соответствующим образом состыковаться. А дальше поверх этого - либо BGP либо STP либо еще что-то.
Если ненадежны не только ваши каналы, но и сами ваши провайдеры, то задача решается либо через "низкий TTL", либо через некую надежную внешнюю точку (предлагаемые выше VPS) и туннели до неё. Возможно стоит применять комбинированные варианты (например сделать предлагаемую схему с туннелями с каждым провайдером, а поверх еще и TTL-переключение навернуть - это уже позволит распараллелить нагрузку).
Однако туннели, низкий ТТЛ - это ИМХО велосипедостроение. нужно стремиться увеличить надежность каналов и организовывать межпровайдерские VLAN-ы, а не туннели. Это качественно иной в плане надежности путь. 100Мбит медяки меняются на 1Gbit и задача аггрегации слегка отодвигается. А если вам надо больше....
>[оверквотинг удален]
> Если ненадежны не только ваши каналы, но и сами ваши провайдеры, то
> задача решается либо через "низкий TTL", либо через некую надежную внешнюю
> точку (предлагаемые выше VPS) и туннели до неё. Возможно стоит применять
> комбинированные варианты (например сделать предлагаемую схему с туннелями с каждым провайдером,
> а поверх еще и TTL-переключение навернуть - это уже позволит распараллелить
> нагрузку).
> Однако туннели, низкий ТТЛ - это ИМХО велосипедостроение. нужно стремиться увеличить
> надежность каналов и организовывать межпровайдерские VLAN-ы, а не туннели. Это качественно
> иной в плане надежности путь. 100Мбит медяки меняются на 1Gbit и
> задача аггрегации слегка отодвигается. А если вам надо больше....Автор пишет что он из ДНР. Соответственно вероятная причина прерывания связи - отключение электричества из-за обстрелов..
Ему нужно техническое решение повышающее высокодоступность которое можно поднять "на коленке", и без всяких наворотов...
[оверквотинг удален]
> Однако туннели, низкий ТТЛ - это ИМХО велосипедостроение. нужно стремиться увеличить
> надежность каналов и организовывать межпровайдерские VLAN-ы, а не туннели. Это качественно
> иной в плане надежности путь. 100Мбит медяки меняются на 1Gbit и
> задача аггрегации слегка отодвигается. А если вам надо больше....Большое спасибо за столь развернутый ответ.
Все-таки, дабы прояснить ситуацию, придется "немного" лирики добавить.
Вы совершенно правы, решать подобные задачи необходимо с привлечением провайдеров, а не сооружать велосипеды. Да только ситуация такова, что на данный момент планировать "по-нормальному" я не могу. Ибо:- военные действия приводят к перебоям связи, прямым повреждением магистралей или нарушением в работе - роутинг, повреждение оборудования провайдеров и т.п. А сервисы должны быть 24/7/365, пофиг на все;
- те же обстрелы вызывают проблемы со электричеством, зачастую не выдерживают UPSы у нас, у провайдеров;
- постоянные dos/ddos атаки;
- это категорически неправильно, но все должно работать уже вчера и как можно скорее. Нет времени на вдумчивую медитацию;
- нет помощи. Нет специалистов. Я же, например, никогда не имел практического опыта работы на таком уровне задач (предыдущее место работы - одно здание, 300 ПК, две подсети, а тут одних только удаленных офисов около 40 и задач - голова кругом). В итоге помощь - гугл, опеннет и все-все-все :) ;
- непредсказуемость и нестабильность ситуации: завтра провов могут поменять, обрубить их насовсем, довесят еще задач, что потребует еще каналов или каких-то сетевых изворотов и т.п.;
- финансирования, как вы понимаете, нет от слова "совсем". Проблемы с оплатой "в мир"- нормально не приобрести даже VPS даже в России.
В общем, все как правильно пишет Square1 on 03-Авг-15, 21:24: нужно хоть как-то "на коленке", криво, косо, сделанное своими силами на нашей стороне, но - чтобы более-менее надежно работало. И - постепенно, как наберусь ума-разума и времени, буду допиливать до "кошерной" нормы...
На данный момент в приоритете таки отказоустойчивость.
можно поставить машинку на том же дебиане из вне обьеденить оба Ip на локалку, дальше просто проброс портов на нужные вам сервисы через iptable, а пользователям сказать - не работает первый ip ломитесь на второй. Т.к. в вашем случае вам ничего даже DNS не поможет. Это надо решать провайдеру такую проблему. В принципе все решается через IPtable кроме того, что на внешней стороне должен быть критически устойчивый выход в инет. но эту проблему вы можете свалить на пользователей дав им 2 ip.
можно поставить машинку на том же дебиане из вне обьеденить оба Ip на локалку, дальше просто проброс портов на нужные вам сервисы через iptable, а пользователям сказать - не работает первый ip ломитесь на второй. Т.к. в вашем случае вам ничего даже DNS не поможет. Это надо решать провайдеру такую проблему. В принципе все решается через IPtable кроме того, что на внешней стороне должен быть критически устойчивый выход в инет. но эту проблему вы можете свалить на пользователей дав им 2 ip. вместо доменного имени.
> можно поставить машинку на том же дебиане из вне обьеденить оба Ip
> на локалку, дальше просто проброс портов на нужные вам сервисы через
> iptable, а пользователям сказать - не работает первый ip ломитесь на
> второй. Т.к. в вашем случае вам ничего даже DNS не поможет.
> Это надо решать провайдеру такую проблему. В принципе все решается через
> IPtable кроме того, что на внешней стороне должен быть критически устойчивый
> выход в инет. но эту проблему вы можете свалить на пользователей
> дав им 2 ip. вместо доменного имени.Как простейший вариант сейчас: мой шлюз с 2-мя входящими каналами, на нем ДНС с записями моих сервисов. Как я понимаю, если юзер обратился по "упавшему" адресу при повторном запросе или автоматом по таймауту (в зависимости от браузера) он таки получит адрес "рабочего" канала. То-есть, юзерам дается инструкция по типу "Если ошибка 404 - обновляете несколько раз страничку, если не срабатывает - лежат оба канала или сервисы". На данный момент это - программа-минимум.
Ибо на пользователей тут особо не свалишь. Если в здании, где я нахожусь, пользователей выдрессировать можно, то на удаленке... Это будет адЪ и израиль в виде постоянных звонков...