Масштабирование CIFS:
взгляд за горизонт с CTDB
Александр Боковой
Samba Team

Четверть века CIFS
• 1984: IBM, Sytec
– проф. Барри Фейгенбаум
• 1985-1998: Intel, 3Com, Microsoft
• 1992: сервер Samba 0.1
– экспорт ресурсов Unix в DOS
• 2008: Samba 3.2

Почему CIFS?
• Кроссплатформенная поддержка
– Windows *, Mac OS X, *BSD, GNU/Linux
• Стандарт де-факто для миллионов
машин (и не только Windows)
• Все альтернативы имеют свои
проблемы

Альтернативы
• NFS v3/v4
• AFS/DFS
• HTTP/WebDAV
• Протоколы кластерных файловых
систем

Альтернативные проблемы
• Блокировки
– «Падчерица» POSIX
– Advisory против Mandatory
– Сброс при закрытии файла (POSIX)
– Вне протокола (NFSv3)
• Блокировки POSIX не готовы к
горизонтальной кластеризации

Проблемы кластерных ФС
• Сетевой координатор блокировок
– Много дополнительного трафика
– Плохое масштабирование (десятки, не
сотни узлов)
• Сервер метаданных
– Плохая локализация метаданных
– Много дополнительного трафика

Если все так плохо, то ...
• К счастью:
– Традиционные POSIX приложения
редко используют файловые
блокировки внутри себя
– Традиционные POSIX приложения
редко требуют координации между
протоколами доступа к одним и тем
же данным

Если все так плохо, то ...
• ... всё может стать еще хуже
– Новые типы нагрузки
– Кросс-протокольный доступ к данным
– Рост неструктурированных данных
• Особенно в Web и социальных сетях

Почему CIFS?
• CIFS удивительно богат
функционально
• Легкость адаптации к новым
нагрузкам
• Хорошая производительность
– Компактный RPC
– Понятная модель кэширования

Особенности CIFS
• Обратная модель ответственности
– Сервер не отвечает за
метаинформацию приложения
– Гибель сессионной информации
некритична
– Автоматическое восстановление
соединений без помощи приложения

Клиенты CIFS
Отдельные сервера CIFS
Локальная файловая
система
Хранение (SAN, DASD)

Samba
• Семантический преобразователь
– Файловые операции
– Учетные записи
– Информация об авторизации
– Информация об устройствах
• 12-15 баз данных в типичной среде

Samba
• Файловые операции
– Богатая семантика Win32
– Более бедная семантика POSIX
– NTCreateX vs CreateFile() vs fopen():
• CreateFile в Win32: 6 параметров
• NTCreateX в CIFS: 13 параметров
• fopen() в POSIX: 2 параметра

Samba и базы данных
• tdb: trivial data base
– Простая база <ключ>:<значение>
– Быстрое чтение, быстрая запись
между процессами
– Отражение в память (mmap) на
большинстве архитектур

Использование
базы данных
locking.tdb для
реализации
семантики
блокировок в
разных вызовах:
от открытия
файла до его
переименования

Посылка сообщений
между процессами
smbd.
Если smbd будут
находиться на
разных узлах, как
посылать сигнал и
обмениваться
информацией в tdb?

Помощь от природы (CIFS)
• Кластерная файловая система
– Не может потерять данные и
метаинформацию
– Принцип «всё или ничего»
• CIFS
– Можно потерять метаинформацию
– За все отвечает клиент

Помощь от природы (CIFS)
• Пример: opendb
– Открытый файл — запись в opendb
– Открыт файл на узле N — информация
только на узле N
– Падение узла — автоматическое
уничтожение записей (и закрытие
файлов)

Помощь от природы (CIFS)
• Восстановление после сбоя
– Пометка записей (RSN = record
sequence number)
– Очистка записей, связанных с узлом N
– Выбор оставшейся записи с
наивысшим RSN
– Результат — прежнее рабочее
состояние

Клиенты CIFS
Виртуальный CIFS
сервер
узлы кластерной
файловой системы
Хранение (SAN,
DASD)

TDB → Clustered TDB
• http://ctdb.samba.org/
• Два уровня поиска записей
– Location master: определение
положения data master
– Data master: определение хранилища
данных

Производительность
Результат теста
NBENCH CIFS
для кластера из
четырех узлов
(Intel dual-core
IBM HS21) и
небольшой
системы хранения
на основе GPFS

TDB → Clustered TDB
• Location master
– Фиксированный хэш по ключу записи
• Data master
– Переменное положение
– Зависит от активности работы с
записью
– Смена владельца через Location master

Диспетчер CTDB