Как я уже упоминал , у нас есть удаленный DRC Oracle standby , куда накатываются изменения локальной базы . Недавно решили развернуть еще одну базу в DRC , гораздо большего обьема .
Сразу было понятно , что передать всю базу ХХ терабайт стандартным путем нереально , время только передачи получалось более месяца . В таком варианте накатывать изменения было уже бессмысленно - переданные данные уже устарели бы.
Отмечу , что к DRC проложены 2 канала - широкий основной и узкий резервный .
Возникла мысль передавать данные по двум каналам одновременно , чтобы использовать свободную полосу основного канала + резервный .
Гугление выявило два варианта - SCTP и Multipath TCP
Тут же выяснилось , что несмотря на описания , SCTP не умеет передавать данные одновременно. Вроде есть патч , но все это в состоянии глубокой альфы .
С MTCP оказалось интереснее . Пачти под дебиан и шапку в наличии и вроде как рабочие . Поставили , начали пробовать .
Действительно , трафик идет по обоим каналам и собирается в конечной точке . Вот только скорость передачи по двум каналам получается меньше чем по одному узкому ..... Короче , с производительностью беда .
Поскольку с параллельной передачей вышел облом , самым разумным показалось сжимать трафик на лету дабы минимизировать обьем передаваемых данных .
Неспешное гугление показало , что продуктов со сжатием трафика немало , но почти все привязаны к протоколу . В 90% случаев - HTTP + RDP и тому подобное . Для наших целей это не подходит совершенно , нужен компрессор IP траффика . Ближе всего в этому софтовые VPN с опцией сжатия .
В итоге оказалось три кандидата -
OpenVPN
tincd
vtun
Последний ранее использовался , но результаты были не очень и сам продукт давно заброшен .
Начали с свежего tincd . Скачал , поставил, настроил , сталь гонять трафик . Результат оказался крайне неутешительным - при потоке более 100 Мбит клиент и сервер сразу стали жрать 100% CPU
Причем даже без сжатия !
С OpenVPN оказалось интереснее . В принципе , он позволял передавать поток с большой скоростью + сжимать его . Вот только стабильных результатов мы так и не достигли . По непоняитным причинам передача файла сегодня проходила со скоростью 270Мбит , а завтра - 120 .
Многочисленные попытки разобраться ничего не дали .
Пришлось вернуться к vtun , он по крайней мере работал стабильно . После небольшого числа тестов удалось найти рабочую конфигурацию и начать передачу данных в DRC .
Примерный порядок получившейся скорости передачи и сжатия виден на картинке -
Зеленый график - это то что прошло по каналу , синий - реальный .
В итоге - передача и накат изменений заняли менее трех недель .
Сразу было понятно , что передать всю базу ХХ терабайт стандартным путем нереально , время только передачи получалось более месяца . В таком варианте накатывать изменения было уже бессмысленно - переданные данные уже устарели бы.
Отмечу , что к DRC проложены 2 канала - широкий основной и узкий резервный .
Возникла мысль передавать данные по двум каналам одновременно , чтобы использовать свободную полосу основного канала + резервный .
Гугление выявило два варианта - SCTP и Multipath TCP
Тут же выяснилось , что несмотря на описания , SCTP не умеет передавать данные одновременно. Вроде есть патч , но все это в состоянии глубокой альфы .
С MTCP оказалось интереснее . Пачти под дебиан и шапку в наличии и вроде как рабочие . Поставили , начали пробовать .
Действительно , трафик идет по обоим каналам и собирается в конечной точке . Вот только скорость передачи по двум каналам получается меньше чем по одному узкому ..... Короче , с производительностью беда .
Поскольку с параллельной передачей вышел облом , самым разумным показалось сжимать трафик на лету дабы минимизировать обьем передаваемых данных .
Неспешное гугление показало , что продуктов со сжатием трафика немало , но почти все привязаны к протоколу . В 90% случаев - HTTP + RDP и тому подобное . Для наших целей это не подходит совершенно , нужен компрессор IP траффика . Ближе всего в этому софтовые VPN с опцией сжатия .
В итоге оказалось три кандидата -
OpenVPN
tincd
vtun
Последний ранее использовался , но результаты были не очень и сам продукт давно заброшен .
Начали с свежего tincd . Скачал , поставил, настроил , сталь гонять трафик . Результат оказался крайне неутешительным - при потоке более 100 Мбит клиент и сервер сразу стали жрать 100% CPU
Причем даже без сжатия !
С OpenVPN оказалось интереснее . В принципе , он позволял передавать поток с большой скоростью + сжимать его . Вот только стабильных результатов мы так и не достигли . По непоняитным причинам передача файла сегодня проходила со скоростью 270Мбит , а завтра - 120 .
Многочисленные попытки разобраться ничего не дали .
Пришлось вернуться к vtun , он по крайней мере работал стабильно . После небольшого числа тестов удалось найти рабочую конфигурацию и начать передачу данных в DRC .
Примерный порядок получившейся скорости передачи и сжатия виден на картинке -
Зеленый график - это то что прошло по каналу , синий - реальный .
В итоге - передача и накат изменений заняли менее трех недель .
