Транспортные альтернативы SSH

не знаю, всегда для таких целей использую netcat, фигачит так что ограничение - сеть или диски.

Сколько ни пробовал nc - всегда получалось медленнееи печальнее, чем через rsync over ssh. Вы с какими ключами nc запускали? Тюнили что-нибудь дополнительно?
Есть подозрение, что выгоднее будет не tar использовать, а cpio..

не знаю... юзал для разных целей. все по дефолту.

-u не использовал.

передавал tar как в вашем примере
передавал просто перенаправлением файл, при этом замерял pps и kbps, если слал между серверами, то ограничение была сеть (точнее даже проц, так как tar gz), если десктоп - то диск. Сеть, правда, гигабитная, не больше.

использующий протокол UDP без подтверждения получения каждого пакета со стороны получателя

И с какой скоростью он тогда должен слать? Будет слать быстро приёмные буфера переполнятся и привет.

надо тестить, что тут скажешь
http://www.spikelab.org/transfer-largedata-scp-tarssh-tarnc-compared/

Кстати, я бы постарался разобраться в чём проблема.

У меня локально nc отрабатывает как надо, проверял как здесь описано: http://deice.daug.net/netcat_speed.html

Известно, что в абсолютном большинстве случаев использование шифрования для передачи файлов - это полный маразм.

Разделение прав?
Необходимость единовременной передачи файлов через интернет?

ИМХО для эпизодического копирования каталога для тех же бэкапов сетевая файловая система - это слегка перебор.

man rsync

К тому же, в OpenVZ ядерный NFS без бубна не поднимешь.

ЕМНИП, NFS-сервер и сейчас можно собрать модулем. Да и закрыть NFS сложнее, чем открыть.

использующий протокол UDP

От него даже в NFS отказались с переходом на v4.

true_admin недавно посоветовал мне перед передачей сжимать чем-нибудь быстрым. Но, да, тоже вручную.

netcat слишком медленный, в том числе и через UDP. Может быть, я не уме его правильно готовить

А измеряешь скорость, копирую в /dev/null?

и нужно как-то приподнять размер передаваемых пакетов...

jumbo frames? Но если NFS не поднимается, так, может, там и с этим плохо.

Ты неправильно готовишь netcat:

host1:
# nc -l -p 666 > /dev/null

host2:
# dd if=/dev/zero bs=1M count=8192 | nc 192.168.123.96 666
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 17.3655 s, 495 MB/s

netrw, проверка чексумм в комплекте. Насчёт быстроты не знаю. Как вообще netcat умудряется тормозить?

Я бы как бы просто оставлю это здесь.

между виртуальными машинами в рамках одного аппаратного хоста

shared folders не забываем.

Странно, что nc у тебя медленно работает.

протокол UDP без подтверждения получения каждого пакета со стороны получателя

Как ты ненавидишь свои данные... Прямо тред «научите меня прищемлять бейцы дверью, а лучше экскаватором!»

между виртуальными машинами в рамках одного аппаратного хоста

в OpenVZ

http://openvz.org/Bind_mounts

torrent

использующий протокол UDP без подтверждения получения каждого пакета со стороны получателя

В качестве примера приведено копирование бэкапа.

Много ты накопируешь с такими хотелками, ага. Или ты поклонник качества перезаписанных по три раза видеокассет и утебя ностальгия?

Известно, что в абсолютном большинстве случаев использование >шифрования для передачи файлов - это полный маразм. Например, >как вам нравится копирование файлов SSH-ем между виртуальными >машинами в рамках одного аппаратного хоста?

Шифрование при передачи информации никогда не бывает маразмом, в том числе и в пределах одного хоста(Если например хост расположен на публичном хостинге). Маразмом является как раз не шифрование данных во время таких пересылок(особенно важных данных). Но, конечно, многое зависит от задачи.

Я знаю про Bind_Mounts, но это некрасивое решение как минимум потому что неуниверсальное. К тому же, задача не получать доступ к данным на другом компьютере в рамках своей файловой системы, а эпизодически КОПИРОВАТЬ данные с другого компьютера. Любые решения с монтированием - вообще не про это.

Как ты ненавидишь свои данные...

Я их очень люблю, но проверку целостности совершенно необязательно делать на уровне транспортного протокола. Тот же NXCore оперирует архиважными бизнес-данными, работает по протоколу UDP и при этом почему-то ничего не теряет. Да и с какого перепуга данные UDP в рамках по сути localhost'а должны куда-то теряться? Разве что в случае полной просадки процессора - но тогда это аварийная ситуация, и там уже вообще речь о копировании каталогов просто не идёт.

Известно, что в абсолютном большинстве случаев использование шифрования для передачи файлов - это полный маразм

4.2

современные процессоры уже лет 10 не тратят много времени на шифрование.

Например, как вам нравится копирование файлов SSH-ем между виртуальными машинами в рамках одного аппаратного хоста?

а зачем вообще организовывать особое сетевое соединение виртуальных машин? Для тестов? Для тестов нужно тестировать ТАКЖЕ, как IRL. Раз IRL тебе требуется шифрование, то и в тесте требуется.

Проще говоря, клиент-серверный режим без намёка на шифрование, использующий протокол UDP без подтверждения получения каждого пакета со стороны получателя. Плюс какие-нибудь полезные оптимизации, сжатие на лету, шифрование...

//fixed

И да, с чего ты взял, что именно шифрование тормозит твою передачу?

всегда получалось медленнееи печальнее, чем через rsync over ssh.

потому что там «оптимизации, сжатие, и шифрование».

мне перед передачей сжимать чем-нибудь быстрым. Но, да, тоже вручную.

значит не такой он и Ъ, ибо

     Compression
             Specifies whether to use compression.  The argument must be ``yes'' or ``no''.  The default is ``no''.

     CompressionLevel
             Specifies the compression level to use if compression is enabled.  The argument must be an integer from 1 (fast) to
             9 (slow, best).  The default level is 6, which is good for most applications.  The meaning of the values is the
             same as in gzip(1).  Note that this option applies to protocol version 1 only.

(man ssh)

протокол UDP без подтверждения получения каждого пакета со стороны получателя

Как ты ненавидишь свои данные...

кто мешает поверх такой передачи привинтить проверку CRC, MD5 и т.д.? К тому же, часто у тебя УЖЕ есть КС, и считать её на передающей стороне не надо. Достаточно просто проверить. Зачем в протокол пихать лишние проверки и поддержание ненужного(в данном случае) соединения?

Т.е. нужно тебе файл закинуть, кидаешь Over9000 датаграм UDP, и не паришься. А там путь разбираются. Если что не дойдёт — ещё раз попросят. Это быстрее, чем устанавливать и поддерживать соединение, да ещё и проверять всякую НЁХ всю дорогу. Ну если большая часть пакетов всё равно доходит, как и есть IRL.

а зачем вообще организовывать особое сетевое соединение виртуальных машин?

Тебе - естественно незачем, а у нас служебные серверы были вынесены в отдельную виртуальную сеть, у пограничных серверов по два интерфейса: наружу для клиентов, внутрь для служебных серверов с файлохранилищем, БД, бэкапами. Есть и другие решения для этого, но суть будет той же: служебные серверы отделены от клиентского сегмента. На локалхосте можно не заморачиваться, можно даже домен просрать, например, и никому ничего не жалко.

Т.е. нужно тебе файл закинуть, кидаешь Over9000 датаграм UDP, и не паришься. А там путь разбираются. Если что не дойдёт — ещё раз попросят.

Чувствуется огромный опыт администрирования локалхоста, который никогда не видел БД, на бэкап которых уходит полночи-ночь. Что ты там заново попросишь? Просрешь бэкап из-за одной битой датаграммы и будешь ждать следующей ночи, молясь, чтобы ничего не навернулось, а в следующую ночь сделаешь как надо, а не «кидаешь Over9000 датаграм UDP, и не паришься».

Тебе - естественно незачем, а у нас служебные серверы были вынесены в отдельную виртуальную сеть

в рамках одного аппаратного хоста

месье знает толк в извращениях.

Есть и другие решения для этого, но суть будет той же: служебные серверы отделены от клиентского сегмента.

почему ты считаешь внутреннюю служебную сеть демилитаризованной зоной? Разве ты никогда не слышал, что подавляющая часть всех атак инициировалась именно изнутри внутренней сети? Либо скоррумпированным устройством/сервером, либо коррумпированным сотрудником, имеющим доступ в эту сеть. Это для тебя новость?

Ну а я вот делаю скажем бекапы зашифрованными. Мало того, сервер может _только_ зашифровать бекап, а расшифровать его невозможно, даже если полностью взломать этот сервер. Думаешь — зачем это надо?

Чувствуется огромный опыт администрирования локалхоста, который никогда не видел БД, на бэкап которых уходит полночи-ночь. Что ты там заново попросишь?

о да… Почитай про репликацию, как она собственно происходит, и почему она работает онлайн, без всяких остановок серверов на ночь, как оно сделано у вас.

Просрешь бэкап из-за одной битой датаграммы и будешь ждать следующей ночи, молясь, чтобы ничего не навернулось, а в следующую ночь сделаешь как надо, а не «кидаешь Over9000 датаграм UDP, и не паришься».

у меня «бекап» делается не «ночью», а 24/7. Если ведомый сервер почему-то не получил информации о транзакции, он запрашивает её по новой. В особо жестоких случаях используется синхронная репликация, когда транзакция вообще не может быть закончена, пока не будет реплицирована.

Ну а вы можете продолжать «ждать ночи», как в 70х годах прошлого века.

почему ты считаешь внутреннюю служебную сеть демилитаризованной зоной?

Фантазии свои оставь при себе, сказочник.

Думаешь — зачем это надо?

Но зачем ты мне все это рассказываешь, я не поддерживал ТС в его нежелании шифровать трафик?

почему ты считаешь внутреннюю служебную сеть демилитаризованной зоной?

Фантазии свои оставь при себе, сказочник.

ты отвечал на моё утверждение «так надо» адресованное ТСу. А он спрашивал «зачем шифровать внутри локалхоста?».

Но зачем ты мне все это рассказываешь, я не поддерживал ТС в его нежелании шифровать трафик?

а почему ты тогда со мной споришь?

Ты такой крутой во всех темах, прям как фантазер.

Где ты увидел, что я с тобой спорю? Я отвечал на вопрос о необходимости особого соединения между виртуальными машинами. О том, что это происходит в рамках одного аппаратного хоста, я упустил, т.к. ты об этом ничего не сказал. Но и в рамках одного хоста виртуальные машины обмениваются информацией не только для тестов, не понимаю почему возник такой вопрос.

Ты такой крутой во всех темах, прям как фантазер.

да? Вот это тоже я написал:

Чувствуется огромный опыт администрирования локалхоста, который никогда не видел БД

Не? Или это ты у нас переходишь на личности?

Я отвечал на вопрос о необходимости особого соединения между виртуальными машинами. О том, что это происходит в рамках одного аппаратного хоста, я упустил, т.к. ты об этом ничего не сказал.

ну я-то откуда знаю твой квадратно-гнездовой способ чтения постов на ЛОРе?

не понимаю почему возник такой вопрос.

глупо предполагать, что из-за протокола UDP, «Просрешь бэкап из-за одной битой датаграммы и будешь ждать следующей ночи, молясь, чтобы ничего не навернулось, а в следующую ночь сделаешь как надо, а не «кидаешь Over9000 датаграм UDP, и не паришься».» про какой-то «бэкап», который почему-то «делается всю ночь» — исключительно твоя фантазия. Как и то, что я тебя заставляю использовать для твоего бекапа протокол UDP.

Я лишь говорил о том, что в некоторых случаях UDP намного быстрее и надёжнее TCP. Но ты можешь дальше фантазировать на тему своих начных поллю^Wбэкапов.

И да, с чего ты взял, что именно шифрование тормозит твою передачу?

Вижу, что по факту на виртуалке 23% ядра отжирается на шифрование.

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

Вижу, что по факту на виртуалке 23% ядра отжирается на шифрование.

ну либо виртуалка кривая, либо ядро кривое(да, в CPU), либо это не только и не столько шифрование.

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

от _этого_ домена больше проблем, чем профитов (точнее профитов от него нет вообще). Пусть уж будет вести на каких-нить киберскоттеров, чем на меня.

мне перед передачей сжимать чем-нибудь быстрым. Но, да, тоже вручную.

значит не такой он и Ъ, ибо

Перешли на личности не разобравшись: ведь я не ssh собирался передавать, а через NFS в доверяемой сети.

А здесь ищут компромисс между NFS и ssh. Но найдут ли, кроме ручного способа...

Перешли на личности не разобравшись: ведь я не ssh собирался передавать, а через NFS в доверяемой сети.

Вы наверное не поняли, что смысл моего сообщения в том, что время собственно шифрования ничтожно. И становится ещё более ничтожным, если применять сжатие. Ибо в ssh сжатие и так УЖЕ есть, и его не нужно прибивать костылями.

А здесь ищут компромисс между NFS и ssh.

а мне непонятна сама нужность этого компромисса. Ну ищите конечно…

Школьник, ты видимо, опять поспешил и не дочитал, что реплики тоже бэкапить надо.

Бэкапятся у него 24/7, муахаха