Alexander Bokovoy Scaling Cifs With Ctdb

Масштабирование 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