The OpenNET Project / Index page

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



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

Оглавление

Для ядра Linux предложена реализация SMB-сервера, opennews (??), 30-Авг-21, (0) [смотреть все]

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


238. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от Аноним (238), 02-Сен-21, 17:11 
> Какой изысканный невероятный бред. Линукс не перестаёт удивлять.

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

Во-первых, SMB - это очень большой протокол, который среди прочего реализует сетевую файловую систему. Схожий протокол, NFS и его серверная реализация в пространстве ядра (knfsd.ko) сколько существует?
Во-вторых, не надо путать протокол SMB и Samba 4.

Я позволю себе вам напомнить, что Samba 3 != Samba 4. Это 2 совершенно разных сервера выполняющих разные задачи. Samba 3, ныне покойная, являлась реализацией протокола SMB, NetBT, WINS и многих других частей устаревшего сетевого стека времен Windows 9x. Не забывайте, что SMB не порождает ни одноранговую сеть ни "Сетевое окружение" не занимается именами, не ведет листинг хостов и тем более не держит на себе ничего что связано с печатью. А между прочим Samba реализует внутри себя тонну служб Windows включая, например, Winbind - посредственную реализацию аутентификации и авторизации. Ну и не забываем про то что Samba испокон веков занимается трансляцией ACL (Маленькое подмножество NT ACL в то что умеет ядро ОС, под которую она собрана).
Samba 4 - это вообще монстр, цель которого, лично мне не ясна, но оно включает в себя огромное количество функций Active Directory и позволяет порождать керберос-реалм... вот это всё ну вообще не рядом с SMB.

Когда читаешь комментарии тут, сразу понятно, что народ путает еще 2 вещи:
1. SMB в изначальном IBM-овском исполнении в связке с NetBIOS. Он известен как SMB1 или CIFS
2. Обновленные SMB исполнении от Microsoft, которому не нужны технологии прошлого века от IBM. SMB 2+
Исторически Samba пыталась реализовать старый SMB1 и ей это удалось. Затем пришел SMB 2, который просто добавили, потому что он проще. А вот SMB 3 содержит внутри себя много функций, которые нельзя производительно реализовать в юзерспейсе. Прежде всего отказоустойчивость (костылики вроде DFS канули в лету), Multichannel для возможности лить данные через конвергентные сетевые адаптеры, утилизируя их целиком, а также поддержка RDMA и организация доставки програмно определяемого стораджа S2D (Storage Space Direct). Вот в юзерспейсе SMB3 банально не имеет смысла.

Дополнительно, нужно отметить что SMB1 официально не поддерживается совместно с SMB3.1. Свежайшая версия стандарта откажется работать с SMB1 прямо на уровне предаутентификации и потребует выключения его поддержки. Нет ничего плохого в том, что он наконец-то заработает в ядре, где ему и место. Samba тут не при чем, это другое. Реализация SMB в Samba - это лишь малая часть её функционала, который накапливался почти 30 лет.

Если говорить про настоящий бред, который происходит в ядре Линукс - это "поддержка ACL". Это касается не только SMB в ядре, но и посредственной поддержки NFS. Дело в том, что в Linux используется недоразумение под названием "Posix ACL", которые официально не входят в стандарт Posix не были приняты и не существуют за пределами Linux. NFS, например, использует NFSv4 ACL свои собственные, а SMB использует SDDL (Security Descriptor Definition Language), который объявляет 256-битные дескрипторы безопасности, идентификаторы в форме S-1-x-xx-xxxxx-xxxxx-xxx на 128 bit и вместе с ними DACL/SACL. И вот ни NFSv4 ACL, ни NT ACL никак не конвертируются в "Posix" ACL, ввиду ограниченности последних. При этом NFSv4 и NT очень близки за тем лишь исключением, что NT ACL поддерживает внутри себя условия проверки утверждений, пришедших из билетов Kerberos 5. То есть, можно просунуть атрибуты LDAP внутрь билетов. Это используется, например, для того чтобы предоставлять доступ пользователю только в том случае, если запрос авторизации поступил с доменного компьютера, который содержится в такой-то такой-то группе ну или там плюс еще какой-то атрибут. Этим функционалом ACL можно пренебречь, на самом деле, ввиду гигантского объема требований (ресурсы и сеть) к топологии развертывания и опять же не имеет отношения к самому главному - передаче данных по сети.

Сообщество Samba одни из тех кто и ACL хотел поменять на нормальные, хоть бы родные для NFS, по-барабану, что не полная поддержка все луче чем то что есть. В случае переноса реализации SMB в ядро, Samba как минимум начнет работать также как NFS. Тоже плохо (ACL и безопасность в юзерспейсе), но всяко лучше чем то что есть.

P.S. Дырки в безопасности о которых все так любят писать - это наличие поддержки SMB1 в пакетах samba-server в дистрибутивах. MS выпилил всем современным вендам этот копролит, а тут получается ни SMB3 не поддерживается ни SMB1 полностью выпилить нельзя. Мрак.

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

240. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноним (240), 02-Сен-21, 19:47 
> Прежде всего отказоустойчивость (костылики вроде DFS канули в лету), Multichannel для возможности лить данные через конвергентные сетевые адаптеры, утилизируя их целиком, а также поддержка RDMA и организация доставки програмно определяемого стораджа S2D (Storage Space Direct).

А можно ссылок на подробности этого? И как применять. Интересно как это выкинуть dfs в географически распределенных системах.

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

243. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от Аноним (238), 02-Сен-21, 23:14 
> А можно ссылок на подробности этого? И как применять.

Начинать читать отсюда: https://docs.microsoft.com/en-us/windows-server/storage/stor...
Если в двух словах, то это применяется для организации гиперковергентного программно определяемого стораджа.
Есть редакции для Hyper-V / System Center и аппаратное применение в рамках Storage Server для современных хранилок с RDMA.
Продолжать тут: https://docs.microsoft.com/en-us/windows-server/storage/file...
В частности Transparent Failover заменяет DFS для создания кластерной отказоустойчиво шары.
https://docs.microsoft.com/en-us/windows-server/failover-clu...
Кроме того никуда не делся Scale-Out File Server для реализации конвергентных хранилок, собственных и от вендоров железа в рамках Storage Server. Это не то же самое, что кластерная шара.

Важно понимать, что DFS и SMB - это теплое и мягкое. DFS - набор открытых протоколов от MS для осуществления файловой репликации поверх старого SMB1, потому что старый SMB не имел никакой отказоустойчивости. DFS сейчас имеет сейчас еще и другую реализацию. Старый FRS уже 10 лет как заменили на DFRS и эта штука используется не для отказоустойчивости, а для задач репликации. Это другое. Вообще DFS это высокоуровневый сервис поверх SMB и много чего еще, а не часть протокола.

> Интересно как это выкинуть dfs в географически распределенных системах.

А чем она у вас там занимается, ваша система? Если у вас шара для совместного использования реальными пользователями, то для этого уже 10 лет как используют WebDAV. В чем смысл такой геораспределения шары, если объектами у вас там являются документы? Опять же автономные копии кэш и синхронизация под WebDAV-каталоги работает лучше чем c DFS.

Если у вас виртуализация и у вас там диски, то DFS такое не тянет по определению. Никакие БД или данные приложений вы так не подключите. Кроме того работа с такой шарой - одно мучение, ведь реальной отказоусточивости нет, а все траблы от мультимастер репликации присутствуют. Даже перемещаемые профили пользователей уехали давно с DFS на кластерные шары/Scale-Out/Storage Spaces.
Дальше всякой мелочевки DFS (каталог с несколькими файликами, типа SYSVOL), которой не нужна ни точность точность ни высокая доступность, и которая готова балансироваться и "геораспределяться" DNS (LOL), её использовать не получится.

Опять же, зачем городить репликацию между файлами в каталоге на нескольких серверах, если можно собрать их в кластер и сделать отказоусточивую быструю шару. Географически распределенная система в этом случае предполагает гиперкластеризацию с регионами (если речь о виртуализации и данных приложений и БД). Администрирующий кластер у вас управляет другими отказоустойчивыми кластерами и перемещает приложения, виртуалки и данные между кластерами и между регионами. Это как раз достигается путем сочетания RDMA и S2D.  При этом наличие конвергентной хранилки никто не отменял. Поверх этого вы уже можете строить любые кластерный шары или отдать один из серверов под Scale-Out. DFS в этом случае еще на уровень выше. Это когда у вас есть 2 шары в разных регионах и вам нужно файлики реплицировать между кластерными шарами... но зачем для этого использовать DFS?! Есть 1001 способ сделать это эффективнее, хотя бы лишь потому что:
- реализация SMB в венде находится в ядре, а DFS - это служба в юзерспейсе.
- DFS работает с полными правами NT ACL и обязана реплицировать и рассчитывать метаданные, SMB работает на низком уровне.

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

248. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноним (240), 03-Сен-21, 20:39 
Ссылки то я и сам нагуглить могу. Интересовало описание живого опыта. Но после этого комментария много прояснилось:
>  DFS сейчас имеет сейчас еще и другую реализацию. Старый FRS уже 10 лет как заменили на DFRS и эта штука используется не для отказоустойчивости, а для задач репликации.
>  Если у вас шара для совместного использования реальными пользователями, то для этого уже 10 лет как используют WebDAV. В чем смысл такой геораспределения шары, если объектами у вас там являются документы? Опять же автономные копии кэш и синхронизация под WebDAV-каталоги работает лучше чем c DFS.

This. Основное интересуемое во всем этом ACL. Ну и отказоустойчивое хранилище.

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

241. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноньимъ (ok), 02-Сен-21, 22:19 
Так эта ядерная реализации реализует доступ к файлам или жуткого монстра со всякими активными директориями и прочей жутью?
Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

242. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноним (238), 02-Сен-21, 22:26 
Доступ к файлам.

Жуткий монстр уже есть, называется Samba 4. Когда реализация SMB переезжает в ядро жуткий монстр начинает использовать ядерную реализацию вместо собственной юзерспейсной.

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

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

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




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

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