The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск Samba 4.15.0, opennews (??), 20-Сен-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "Выпуск Samba 4.15.0"  +1 +/
Сообщение от Аноним (22), 21-Сен-21, 00:56 
Смотря для чего. Быстро и эффективно - rsync (обычно достаточно), нужна поддержка мастдая и ad - samba, нужна распределенность - glusterfs. Много нюансов, можно ещё nfs, zfs, moosefs, catapult вспомнить, у каждого свои бонусы в зависимости от целей и клиентов.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

26. "Выпуск Samba 4.15.0"  +/
Сообщение от Анончик (?), 21-Сен-21, 03:35 
а где божественный nbd?
Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск Samba 4.15.0"  +2 +/
Сообщение от пох. (?), 21-Сен-21, 09:56 
в первые десять ответов гугля у него не поместился. Судя по zfs вперемешку с gluster - именно оттуда исходит свет знания.

P.S. у нормально настроенной самбы скорость непосредственной передачи файликов примерно и равна ftp. Ну, была. Что там теперь с  Multi-Channel будет - сомневаюсь что хорошо. Поскольку все попытки заменять костылями неумение в tcp всегда заканчивались одинаково.

Вопрос что проще нормально настроить - в разных случаях имеет разные ответы.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (150), 21-Сен-21, 16:07 
Странно что гугля не выдало ему про вебдав ничего. Самое простое решение работы для всех пользователей. А у него там каша вперемешку с соплями.
Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск Samba 4.15.0"  –1 +/
Сообщение от пох. (?), 21-Сен-21, 17:40 
для пользователей оно ничем не проще чем обычный smbfs shared folder.

Для админа самба проще и понятнее в настройке. Раз уж с nfs нам неповезло а ftp немодно и немолодежно.

Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (150), 21-Сен-21, 18:52 
Вин, мак, лин, фря, ведроид, огрызок. Что там проще будет?
Ответить | Правка | Наверх | Cообщить модератору

96. "Выпуск Samba 4.15.0"  +/
Сообщение от пох. (?), 21-Сен-21, 19:48 
гугледок какой-нибудь.

Я не вижу смысла в _совместной_работе_с_файлами_ (для которой предназначены сетевые fs) с перечисленного. Понятия не имею ни что вы с ними делать собрались, ни - зачем.
Совместная работа с документами - возможна, но это не про файлы вообще.

Совместная работа с файлами с нормальных компьютеров - вполне проста и эффективна именно через samba/smbfs.

Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск Samba 4.15.0"  +/
Сообщение от Ivan_83 (ok), 22-Сен-21, 03:55 
Вебдав клиент в венде никакой, fuse на линухах тоже фиговый.
В итоге технология мне в принципе нравится, но годных реализаций нет нигде.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

127. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (28), 22-Сен-21, 07:05 
Если ты его помнишь со времен XP, то его уже переписали. Старый тоже оставили.
Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск Samba 4.15.0"  +/
Сообщение от Ivan_83 (ok), 23-Сен-21, 05:32 
Нет, WebDAV клиент я помню со времён семёрки, где он мог до 4гб файлы жрать, и каждый раз выкачивал их целиком к себе, даже если тебе только посмотреть что в начале файла.
Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск Samba 4.15.0"  +/
Сообщение от kissmyass (?), 21-Сен-21, 16:35 
Все нормально с multi-channel, тестил F33 и Win7 - забивает 10G линк полностью на обычном CPU 10-летней давности, главное настроить правильно, сначала добиться нормальной скорости через iperf, а потом уже смотреть, что тюнить у самбы.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

84. "Выпуск Samba 4.15.0"  +/
Сообщение от пох. (?), 21-Сен-21, 17:24 
Для того чтоб получить чуть выше 800mb/s - не нужен никакой multichannel, вообще.

И "правильно настраивать" тоже особо нечего. Ну может десять лет назад какие-то kernel tunables и имело смысл крутить, но скорее всего и дефолты были уже разумными.

Правда, сервером была фря. В линуксе как-то и не с чего было тогда отдать 800.

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск Samba 4.15.0"  –1 +/
Сообщение от kissmyass (?), 21-Сен-21, 18:04 
> Для того чтоб получить чуть выше 800mb/s - не нужен никакой multichannel,
> вообще.
> И "правильно настраивать" тоже особо нечего. Ну может десять лет назад какие-то
> kernel tunables и имело смысл крутить, но скорее всего и дефолты
> были уже разумными.
> Правда, сервером была фря. В линуксе как-то и не с чего было
> тогда отдать 800.

сравнил ты фрю и линукс, не знаю что там в хре, но в линухе нужно параметры кернела менять, увеличивать размер буфера и бла бла, и jumbo frame надо разрешить в свиче

и не 800, а 980 MiB/s

я бы ради интереса отключил мультиканал, но мне откровенно говоря лень сейчас тестами заниматься

Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (28), 22-Сен-21, 07:13 
Гражданин, вам бы LAG собрать, чтобы тестами мультиченела заниматься. Не обязательно 10G+10G, но именно 802.3ad. Необходимость мультиканала на одном линке да на таких обычных скоростях как-то малопонятна.
Ответить | Правка | Наверх | Cообщить модератору

130. "Выпуск Samba 4.15.0"  +/
Сообщение от пох. (?), 22-Сен-21, 08:55 
И чем он тебе отдаст 1500+гб ?

> Необходимость мультиканала на одном линке да на таких обычных скоростях как-то малопонятна.

его необходимость вообще малопонятна. По-моему от него опять один вред будет. Типа засирания канала из-за неправильной работы congestion control. Переизобретатели tcp - они по другому не умеют.

Скорее это делалось для как раз плохих каналов с задержками и потерями, типа vpn для эндюзера.

Мда... как все же жаль, что мне не удалось сохранить третью версию сосамбы в живом виде :-(

Ответить | Правка | Наверх | Cообщить модератору

171. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (28), 22-Сен-21, 17:58 
> его необходимость вообще малопонятна.

Представь что у тебя есть 2 ToR-свитча в MLAG и 4 порта по 25G на сервере, ты воткнул это всё и настроил на коммутаторах LAG, раздаёшь LACP, и у тебя транк в котором VLAN-ы.
А еще у тебя настроен CoS на резервирование 50% буферов на 4-й очереди. И есть PFC c разносом это по приоритетам 802.1p и есть ETS, анонсирующий очереди коммутатора в DCBX и у тебя заведены в коммутатор соответствующие TLV или используются автоматические TLV (зависит от марки/модели свитчей). Ты получил свою lossless-очередь, и вот теперь ты её шейпишь сверху до 50G. А ну и серверов у тебя таких, например 4 штуки.
В этой ситуации в приоритете 4 у тебя есть VLAN пригодный для задач RoCE.

И вот на этих серверах у тебя сторадж поверх SMB в triple mirror. Диски и NVMe-кэш, ясен пень у тебя в серверах локально.

В этой ситуации у тебя сохраняется проблема единого логического линка LACP, потому что MLAG даст тебе балансировку при переходе траффика из ToR в Spine. Вот тут-то ты и утилизируешь свой мультиканал.

> типа vpn

Вообще, я бы не рекомендовал использовать RoCE, а применил бы RoCEv2 как раз из-за работы по UDP/IP.
У тебя тогда может быть даже не 1 LAG на 4 порта, а 2 по 2. В первом у тебя данные, а во втором сторадж. Причем в LAG для дранных приходит trunk, а LAG для стораджа может быть в access. И у тебя настроен мапинг DSCP в 802.1p, например CS6 -> 4. И ты классифицируешь траффик по DSCP с нетегированного порта (а сервак настроен это правильно помечать) и привязываешь это к PFC/ETS/DCBX.

Разница будет как раз в поведении во всяких VPN. Представь что у тебя есть второй ДЦ в котором всё то же самое и есть несколько L2VPN. И вот в первом случае ты гонишь тегированный трафик с PFC через L2VPN с использованием мостов на обоих сторонах. Тегированные VLAN-ы с lossless-траффиком попадают тегированными в мост. И вот в случае RoCEv2 у тебя... обычный IP траффик с DSCP пометкой в обычной VPN. Очереди на роутерах ты опять настраиваешь сам.

В этом случае задача не обязательно миграция данных. Это может быть единый кластер на двух локациях присутствует в виде зеркала для задач отказоустойчивости. То есть это еще одно зеркало "единого стораджа" не будет, задержки там тоже не так важны.
Ключевая разница в том, что у тебя может быть несколько VPN, но сеть сеть не применяет ECMP-роутинг. И вот тут опять тебе на выручку приходит мультиканал.

Для юзера, который ходит на шару в формате \\hostname это всё действительно малопонятно, но вот если у тебя есть Scale-Out кластер с этой шарой на которую ты бекапишь это всё, то мультиканал вновь обретает смысл.

> Переизобретатели tcp - они по другому не умеют.

Переизобретатели TCP изобрели iWARP и предлагают совать TCP over TCP для передачи файлов и блочных данных. Intel уже вроде отказался от своих велосипедов, а Chelsio не унимается. Я даже не буду рассказывать какой там монстр получился, сам почитай. Киллерфича в том, что мы хотим как Infiniband, но не будем настраивать CoS на коммутаторе, авось и так проканает. Ведь у нас TCP и гарантированная доставка. А потом, когда невменяемые задержки такого стораджа поверх iWARP шатают производительность всего что с ним работает предлагают... ты не поверишь... заплетать косы на коммутаторах да не как-нибудь, а именно через Data Center Bridging, то есть именно то что нужно было изначально для UDP-решений. С чем боролись на то и напоролись.

Одно радует, что великодушный Microsoft позаботился о бомжах^W дауншифтерах и теперь выпускает SMB over QUIC (iWARP от этого станет лучше) еще и с поддержкой Let's Encrypt. Я сейчас не шучу. Это новая версия SMB в Server 2022.

А вообще ты прав, эти технологии при неправильном использовании так фигурно могут положить (поставить на паузу) целый сегмент сети или сожрать траффик в VPN. Но тут проблема прямоты рук, точки роста рук и, немножечко, мозгов.

> Мда... как все же жаль, что мне не удалось сохранить третью версию сосамбы в живом виде :-(

Раз Microsoft столь великодушен к бомжам^W дауншифтерам, то может это всё запилят в форме модуля ядра, чтобы потом можно было это юзать мимо монструозной сосамбы 4...

Ответить | Правка | Наверх | Cообщить модератору

157. "Выпуск Samba 4.15.0"  +/
Сообщение от kissmyass (?), 22-Сен-21, 14:25 
> Гражданин, вам бы LAG собрать, чтобы тестами мультиченела заниматься. Не обязательно 10G+10G,
> но именно 802.3ad. Необходимость мультиканала на одном линке да на таких
> обычных скоростях как-то малопонятна.

At least one of the following configurations:
    Multiple network adapters
    One or more network adapters that support Receive Side Scaling (RSS)
    One of more network adapters that are configured by using NIC Teaming
    One or more network adapters that support remote direct memory access (RDMA)

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

167. "Выпуск Samba 4.15.0"  +/
Сообщение от Аноним (28), 22-Сен-21, 16:47 
Ну смотри, про RSS и RDMA забудь на пару лет, потому что пока реализация SMB 3.11 не переедет в ядро из юзерспейса эти технологии не работают в привязке конкретно к Samba.
А вообще по тексту ты походу это забрал из доки про Azure HCI... так вот, Multiple network adapters - это с учетом дефолтного поведения венды, которого на линуксе нет.
Тебе в этой ситуации нужно использовать:
1) имена для шар
2) должен работать DNS Scavenging, это когда полученные по DHCP или вручную IP-адреса анонсировались в прямую зону DNS-сервера. Ожидать что это будет работать по NetBT и тем более полагаться за обмен этими именами и lmhosts/wins со стороны самбы я категорически не рекомендую
3) Нужны AAAA-записи в DNS, потому что на венде всё SMB работает по локальным скоупам IPv6 в первую очередь.

Чтобы не морочить голову с DNS проще настроить LACP, это как раз оно:
One of more network adapters that are configured by using NIC Teaming

ИМХО, мороки меньше, потому что тесты через разные IP и правильные имена... winbind-ом в домен её вгонять, или sssd юзать вместо winbind, или надеяться на NetBIOS over TCP/IP без домена... такое себе.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру