Olegator
|
|
« : 23-03-2005 21:04 » |
|
Здравствуйте. Можно ли сделать RAID массив из телефонных линий для увеличения скорости закачки файлов. Т.е. сидят 10 человек в сети у пяти из них выход в инет. Можно ли через них сделать один интнернет с одним провайдером так чтобы качалось всё быстрее в 5 раз.
|
|
|
Записан
|
|
|
|
vasyav
Гость
|
|
« Ответ #1 : 24-03-2005 07:40 » |
|
Можно, только это называеться не RAID масив, а лоад балансинг. Тебе нужно распределить нагрузку на сущ. каналы.
Но что б ускорить закачиваемость файлов можно только, если договориться с прововайдером, что б он у себя настраивал это.
|
|
|
Записан
|
|
|
|
Olegator
|
|
« Ответ #2 : 24-03-2005 08:56 » |
|
Но что б ускорить закачиваемость файлов можно только, если договориться с прововайдером, что б он у себя настраивал это.
Это реально такое существует, что можно договориться с провайдером или это твоё предположение?
|
|
« Последнее редактирование: 24-03-2005 09:03 от Olegator »
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #3 : 24-03-2005 19:57 » |
|
Load balancing организовать без взаимодействия обеих сторон невозможно. Точнее можно включить его с одной стороны, но из этого выйдет совершенная фигня. А то, что провайдер не пойдет на извращения с дайлапом - это точно. Да и сложно это сделать с провайдерской стороны. Этот вопрос уже обсуждался - см. тему /index.php/topic,5170.0.html .
Я же хотел бы обсудить теоретические и практические вопросы _имитации_ loadbalancing на транспортном уровне. Причины выбора транспортного уровня, а не сетевого ищи в вышеупомянутой теме в моих постах (эх, не хотели они меня там слушать совершенно).
Реализовывать будем на Linux с ядром 2.4 или старше, используя утилиты пакетов iproute2 и iptables. Почему Linux? Просто потому, что я его неплохо знаю и у него гибкая сетевая система, для настройки которой не надо прилагать больших усилий или быть гигантом мысли. Прежде всего я рассматриваю принцип работы, а объяснять лучше на примерах, а не абстрактно.
Железо - простой PC с одной ethernet картой и 5-ю модемами для коммутируемых линий. Через какое железо эти пять модемов будут подключаться, как инициализироваться и т.п., я опускаю - это вторично.
Локальная сеть у нас будет на интерфейсе eth0 c адресом 192.168.1.1 и маской 255.255.255.0 (/24). Модемы будут управляться демонами pppd, создающими интерфейсы ppp0...ppp4. Адреса назначает провайдер.
Балансирование на транспортном уровне (соединения в TCP, взаимосвязанные пакеты в UDP и ICMP) и поддержание целостности этих потоков будет выполнять сетевая подсистема connection tracking и правила трансляции адресов SNAT и MASQUERADE.
И так по порядку...
1) С одной из машин в локальной сети пришел пакет, предназначенный для машины в интернете. Промаркируем пакет посредством правила MARK числом 1.
iptables -t mangle PREROUTING -i eth0 -s 192.168.1.0/24 -d ! 192.168.1.1 -j MARK --set-mark 1
2) Направим этот пакет в интерфейс локальной петли (lo). Для этого создаем таблицу 10 маршрутизации с единственным маршрутом по умолчанию. Потом задаем правило, по которому пакет, промаркированный "1", будет направлен в таблицу 10.
ip route add table 10 dev lo default ip rule add fwmark 1 prio 1 table 10
3) Когда маршрут пакету уже назначен, сделаем для него правило трансляции source адреса. При этом, если указать несколько адресов, то они будут использоваться покругу (round robin). В подсистеме connection tracking это правило преобразования адресов будет зафиксировано и следующие пакеты из этого соединения, а так же ответные пакеты будут преобразовываться по этому правилу и с тем же IP.
iptables -t nat -A POSTROUTING -o lo -s 192.168.1.0/24 -d ! 192.168.1.1 -j SNAT --to-source 127.0.1.0-127.0.1.4
4) Попав в локальную петлю (чисто программный сетевой интерфейс, у которого пакеты, выходящие через него, попадают сразу на его же вход), пакет вернется в систему через тот же интерфейс lo. Теперь у нас пакеты одного соединения имеют один source IP, а всего есть пакеты с 5-ю разными source IP: с 127.0.1.0 по 127.0.1.4. Теперь их можно различать и направить по разным маршрутам - через разные модемы. Для этого создадим 5 таблиц маршрутизации и по одному маршруту в каждой. Так же создаем пять правил маршрутизации по source IP.
ip route add table 1 dev ppp0 default ip route add table 2 dev ppp1 default ip route add table 3 dev ppp2 default ip route add table 4 dev ppp3 default ip route add table 5 dev ppp4 default
ip rule add from 127.0.1.0 prio 1 table 1 ip rule add from 127.0.1.1 prio 1 table 2 ip rule add from 127.0.1.2 prio 1 table 3 ip rule add from 127.0.1.3 prio 1 table 4 ip rule add from 127.0.1.4 prio 1 table 5
5) Наконец, пакету надо выдать полноценный source IP, с которым он сможет пройти по сети провайдера, попасть в интернет и достичь IP назначения (destination IP). Используем для этого правило MASQUERADE (маскарад). При этом пакету будет назначен source IP интерфейса, через который он уходит. Конечно же это будет зафиксировано в connection tracking.
iptables -t nat -A POSTROUTING -s 127.0.1.0/24 -j MASQUERADE
6) Вот пакет и на свободе, да мало отправить пакет - надо еще и доставить ответный. Ответный пакет войдет по тому же интерфейсу, по которому вышел наш предыдущий пакет. При этом он будет преобразован подсистемой connection tracking: получится пакет с destination IP равным одному из 127.0.1.0...127.0.1.4 - такому же, который был в source IP первого пакета. При этом ему подойдет маршрут 127.0.0.0/8, который стандартно присутствует при поднятом lo.
7) Теперь пакет вошел с интерфейса lo. Опять сработала подсистема connection tracking (см. пункт 3) и пакет получил свой destination IP в локальной сети. Теперь он пройдет маршрут 192.168.1.0/24 и выйдя через eth0 попадет на машину, с которой ушел наш первый пакет.
Вот такой во принцип. Проще не у меня не получается. Реализовывать еще не пробовал. К тому же, у меня тем 5-и модемов и их некуда цеплять. Конечно можно экспериментировать на виртуальных машинах типа VMware или VirtualPC. Конечно я тут не рассказал про тонкости работы pppd и т.п - полуучилось бы значительно длинее и запутаней.
Если есть вопросы - прошу задавать. Если у меня в рассуждениях есть ошибки - прошу указать и пояснить.
|
|
« Последнее редактирование: 24-03-2005 20:07 от RXL »
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Sla
|
|
« Ответ #4 : 25-03-2005 07:10 » |
|
Красиво Но вот эту бы штучку еще и в космос запустить
|
|
|
Записан
|
Мы все учились понемногу... Чему-нибудь и как-нибудь.
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #5 : 26-03-2005 23:11 » |
|
Вот такой однопроходный и простой вариант возможен, если в есть match nth и target ROUTE - в ядре и в iptables. iptables -t mangle -N mpr_route_new iptables -t mangle -A mpr_route_new -m nth --every 5 --start 0 -j CONNMARK --set-mark 1 iptables -t mangle -A mpr_route_new -m nth --every 5 --start 1 -j CONNMARK --set-mark 2 iptables -t mangle -A mpr_route_new -m nth --every 5 --start 2 -j CONNMARK --set-mark 3 iptables -t mangle -A mpr_route_new -m nth --every 5 --start 3 -j CONNMARK --set-mark 4 iptables -t mangle -A mpr_route_new -m nth --every 5 --start 4 -j CONNMARK --set-mark 5 iptables -t mangle -N mpr_route_next iptables -t mangle -A mpr_route_next -j CONNMARK --restore-mark iptables -t mangle -A PREROUTING -m state --state NEW -s 192.168.1.0/24 -d ! 192.168.1.1 -j mpr_route_new iptables -t mangle -A PREROUTING -m state --state ESTABLISHED -s 192.168.1.0/24 -d ! 192.168.1.1 -j mpr_route_next iptables -t mangle -A PREROUTING -m state --state RELATED -s 192.168.1.0/24 -d ! 192.168.1.1 -j mpr_route_next iptables -t mangle -A POSTROUTING -m connmark --mark 1 -j ROUTE --oif ppp0 iptables -t mangle -A POSTROUTING -m connmark --mark 2 -j ROUTE --oif ppp1 iptables -t mangle -A POSTROUTING -m connmark --mark 3 -j ROUTE --oif ppp2 iptables -t mangle -A POSTROUTING -m connmark --mark 4 -j ROUTE --oif ppp3 iptables -t mangle -A POSTROUTING -m connmark --mark 5 -j ROUTE --oif ppp4 iptables -t nat -A POSTROUTING -o ppp+ -s 192.168.1.0/24 -j MASQUERADE
Конечно не тестировал.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
vasyav
Гость
|
|
« Ответ #6 : 28-03-2005 06:59 » |
|
Привет.
Помойму вы разказываеться как отдавать файлы на разные интерфейсы. Но не факт что приходить они будут тоже на разные. Приходить пакеты из вне будут только на тот девайс с которым сервер установил соединение.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #7 : 28-03-2005 19:40 » |
|
vasyav, причем тут файлы? Помоему тут путаница в терминологии. Я не могу однозначно понять, о чем ты хотел сказать. Расскажи, пожалуйста, еще раз.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
vasyav
Гость
|
|
« Ответ #8 : 29-03-2005 06:37 » |
|
2 RXL Можно ли сделать RAID массив из телефонных линий для увеличения скорости закачки файлов.
Насколько я понял из первого поста именно это и требуеться. Увеличить скорость получения информации из инета. Все файлы отдаються по ТСП протоколу. А этот протокол с предварительной установкой соединения. Таким образом, я считаю, что осуществить это не договариваясь с провайдером не возмонжно. Даже используюя сильно хитрую технику с маршрутизацией.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #9 : 29-03-2005 08:43 » |
|
vasyav, ответ следует читать чуть ниже - мой первый пост. Load balancing организовать без взаимодействия обеих сторон невозможно. Точнее можно включить его с одной стороны, но из этого выйдет совершенная фигня. А то, что провайдер не пойдет на извращения с дайлапом - это точно. Да и сложно это сделать с провайдерской стороны. Этот вопрос уже обсуждался - см. тему /index.php/topic,5170.0.html . И как следствие: Я же хотел бы обсудить теоретические и практические вопросы _имитации_ loadbalancing на транспортном уровне. Причины выбора транспортного уровня, а не сетевого ищи в вышеупомянутой теме в моих постах (эх, не хотели они меня там слушать совершенно). Так же хочу добавить, что на скачку одного файла в один поток предложенный мной метод не повлияет, но распределит групповую нагрузку от нескольких машин локальной сети, а это, между прочим, в вопросе есть.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
vasyav
Гость
|
|
« Ответ #10 : 29-03-2005 09:02 » |
|
Ок, предлагаю, следующее - сначала эксперемент, затем результаты эксперимента в студию. А так получаеться глупый флейм. Каждый считает свой пост правильным.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #11 : 29-03-2005 10:20 » |
|
vasyav, у меня сейчас на эксперимент нет ни времени, ни желания. Если хочешь, то попробуй проверить сам - описание даю ниже. А так получаеться глупый флейм. Каждый считает свой пост правильным. С этим утверждением пока не согласен - если у собеседника есть желание разобраться, а не только упираться рогом, то флеймом это считать не стоит. Давай разберемся: я написал несколько развернутых и тщательнейшим образом разжеванных постов (я понимал, что другие участники беседы могут не знать теорию маршрутизации и особености Linux-а), а от тебя я пока услышал только сомнения, но нет ни фактов, ни пояснений - ничего. Так что, если хочешь продолжать обсуждение, то будь добр отвечать развернуто. Если считаешь, что работать не будет - поясни почему.
Описание модели: Для моделирование нужно две виртуальные машины в качестве роутеров клиента и провайдера, а так же еще пару вирт.машин для иммитации машины в локальной сети и машины в интернете, или какая-либо другая иммитация для тестирования прохождения пакетов через модель (трафик непосредственно между роутерами не подойдет). Роутеры нужно соединить несколькими каналами, через которые будем балансировать трафик. Я думаю, что выбор носителя тут не важен - легче всего сделать это через несколько VLAN (802.1q) по одной ethernet-сети, или через несколько ethernet-сетей (VMware позволяет создать 8 штук host only). Проверка правильности распределения пакетов: 1) Создать одиночное TCP-соединение, прогнать но нему пару пакетов, завершить. Проверить счетчики пакетов на интерфейсах. Убедиться в том, что серия пакетов одного соединения прошла по одному и тому же интерфейсу. 2) Повторить шаг 1 несколько раз. Убедиться, что для каждого соединения выбирается другой интерфейс. 3) Проделать аналогично с ICMP и UDP. В качестве генератора пакетов можно использовать утилиты ping и traceroute, а так же различные UDP сервисы (DNS, TFTP, TIME и т.п.). 4) Поменять IP "машины в локальной сети" на другой из той же сети и повторить шаги 1, 2 и 3. Если в концепции изъян, но проверка заглохнет еще на первом шаге. Если эксперимент прошел удачно, то параллельную передачу нескольких соединений через разные интерфейсы можно и не проверять - тут достаточно логики.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
vasyav
Гость
|
|
« Ответ #12 : 30-03-2005 07:03 » |
|
Вообще-то я считаю, ты предложил ты и должен доказывать что это работает. Мне тоже не сруки начинать собирать все это. У меня нет не времени не ресурсов пока. И не нужно на данный момент.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #13 : 30-03-2005 23:47 » |
|
vasyav, тебе лично я ничего не должен. Да и никто тут ничего никому не должен - все мы действуем добровольно. Извини, если грубовато пояснил, но других слов не нашел.
Мне самому интересен результат. Будет возможность - проверю. Конечно на упрощенной модели - не с модемами. По первому примеру уже могу сказать без проверки - работать не будет. Я не учел то, что маршруты в Linux-е кешируются - не каждый день с этим сталкиваешься - забыл. Второй вариант (с nth и ROUTE) мне кажется более реальным. Посмотри в блогах club.shelek.com - там я запостил новость по поводу свежего перевода advanced routing HOWTO - там есть примерчик балансировки исходящих соединеий без iptables. Правда то же не без изъяна.
Если не вдаваться в проблемы реализации, то принцип простой: на стороне клиента надо отдавать все пакеты одного соединения по одному и тому же маршруту с тем же src ip; провайдерская сторона будет работать как обычно - маршрутизация по dst ip.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Olegator
|
|
« Ответ #14 : 01-04-2005 00:06 » |
|
Можно ли сделать так, чтобы файл качался не сначала, а с определённого места?
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #15 : 01-04-2005 10:54 » |
|
Olegator, это относится уже не к данному попросу, а к возможностям протокола, посредством которого ты переправляешь файл. Если брать интернет, то в FTP и HTTP такая возможность существует - дело за поддержкой в программах. Нарпример, для скачки файлов из инета воспользуйся качалкой (reget, flashget и т.п.) - они могут и докачивать, и качать в несколько потоков.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Olegator
|
|
« Ответ #16 : 01-04-2005 13:38 » |
|
Olegator, это относится уже не к данному попросу, а к возможностям протокола, посредством которого ты переправляешь файл. Если брать интернет, то в FTP и HTTP такая возможность существует - дело за поддержкой в программах. Нарпример, для скачки файлов из инета воспользуйся качалкой (reget, flashget и т.п.) - они могут и докачивать, и качать в несколько потоков.
Это я всё и так знаю. И вопрос всётаки по теме. Можно ли сделать так, чтобы пол фильма качалось у меня, а пол фильма у друга. Пускай даже с разными соединениями.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #17 : 01-04-2005 21:16 » |
|
Не понимаю, в чем смысл вопроса... Уж не хочешь ли ты сделать диверсию - рвать скачку на середине? В общем, не хочу гадать - могу неправильно понять.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
Olegator
|
|
« Ответ #18 : 01-04-2005 21:27 » |
|
Всё очень просто. Хочу по быстрому закачать фильм. В одиночку 650 Мб качается часов 40, а в двоём за 20.
|
|
|
Записан
|
|
|
|
RXL
Технический
Администратор
Offline
Пол:
|
|
« Ответ #19 : 01-04-2005 21:57 » |
|
Вот я и говорю, что к данной теме отношение не имеет.
При скачке с начала: просто оборви соединение по получению нужного количества байт. Скачка фрагмента: отправь составленный вручную HTTP запрос, в котором будет сказано с какого байта начать, и принимай данные. Это конечно программно - не знаю какой софт такое делает.
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
|