Юрий Трухин (InfoboxCloud)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,142
On Slideshare
348
From Embeds
794
Number of Embeds
4

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 794

http://www.xakep.ru 717
http://ritconf.ru 41
http://xakep.ru 35
http://www.highload.ru 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Распределенные   отказоустойчивые  файловые   системы  HA  DFS   Юрий  Трухин    cloud  compu1ng  expert  
  • 2. План  выступления  
  • 3. Причины   •  Количество  данных  в  дата-­‐центрах  растет   •  Требуется  быстрый  доступ  к  данным     •  Требуется  высокая  доступность  данных   •  Гибкость  и  низкая  стоимость  
  • 4. Где  использовать?   •  CDN   •  Бекап  и  архивация   •  Масштабируемые  файловые  сервера   •  HPC   •  IaaS  Storage   •  Хранение  блобов  баз  данных  
  • 5. Устройство  HA  DFS   •  Сервер  данных  (CS):  содержимое  файлов  или  кусков   данных     •  Сервер  метаданных  (MDS):  хранят  информацию  о   данных  и  их  репликах.  При  использовании  кусков   данных  хранит  информацию  о  том,  как  собрать   куски  в  файлы.  Управляет  версиями  и  может   хранить  лог  событий  на  кластере.   •  Клиент:  использует  API  для  управления  данными,   связывается  с  MDS  и  CS  
  • 6. GlusterFS   •  объединяет  существующие  файловые  системы   (рекомендуется  XFS)   •  Включает  в  себя  NFS3  сервер   •  Для  пула  кластера  использовать  /etc/hosts   некрасиво  и  ненадежно.  Используйте  DNS.   •  Рекомендуется  использовать  NTP.   •  Работает  в  UserSpace  через  FUSE.   •  Posix–совместимая  HA  DFS  
  • 7. GlusterFS   •  Считается  хеш  от  имени  файла,  делится  по   модулю  по  кол-­‐ву  имеющихся  серверов  для   определения  места.   •  При  переименовании  файла  оставляет  свой   новый  адрес  на  старом  месте.   •  Для  увеличения  числа  файловых  серверов  –   extensible  hashing  (увеличение  значения  хеш-­‐ функции  без  пересчета  хешей).   •  Нет  сервера  метаданных.   •  Данные  записываются  сразу  на  несколько  нод.   С  2мя  нодами  не  лучше  rsync.  
  • 8. GlusterFS  Pro   •  Любое  оборудование  без  каприз  (собирается   даже  на  arm)   •  Автоматическое  восстановление  при  сбоях   •  Нет  центрального  сервера  метаданных   •  Возможно  добавление  нод  по  мере  роста   •  Простая  установка.  Правда.  8  шагов.  Отличная   документация.   •  Возможно  подключение  через  стандартные   протоколы  NFS,  SMB/CIFS  или  нативный   клиент.  
  • 9. GlusterFS  Pro   •  На  множестве  серверов  быстрый   произвольный  доступ  к  файлу,  если  файл   читает  небольшое  количество  клиентов.   •  Возможно  увеличение  тома  при  добавлении   нового  сервера.   •  Поддерживает  локи  на  файлы  через  posix-­‐ locks,  о  которых  сообщает  всем  томам.   •  Поддерживает  асинхронную  георепликацию.  
  • 10. GlusterFS  Contra   •  Без  репликации  потеря  сервера  –  потеря  всех   данных  на  сервере.       •  Если  файл  больше  размера  тома  –  случится   ошибка  записи.   •  Если  файл  не  там,  где  вычислен  хеш  –  будет   долгий  поиск.   •  ls  работает  медленно  тк  нет  сервера   метаданных  –  нужно  обежать  все  сервера.  
  • 11. Компоненты   •  glusterd  управляет  эластичным  томом,   соответственно  должен  быть  запущен  на  всех   серверах,  где  необходимо  монтировать  FS.   Управляется  через  gluster  cli.   •  glusterfsd  управляет  brick  томами,  по  процессу   на  том.  Управляется  glusterd.   •  glusterfs  занимается  NFS,  FUSE  клиентами  и   обеспечением  здоровья  системы   •  mount.glusterfs  инструмент  для  монтирования   через  FUSE   •  gluster  интерфейс  CLI  
  • 12. Трансляторы   GlusterFS  использует  расширяемый  механизм   трансляторов  (можно  писать  свои).   storage  –  сохраняет  и  получает  данные  из   файловой  системы  
  • 13. Трансляторы   cluster  –  занимается  распределением  и   репликацией  данных,  записью  и  чтением  из   хранилища  bricks  
  • 14. Трансляторы   debug  –  предоставляет  интерфейс  и  статистику  по   ошибкам  для  отладки.   encryp^on  –  на  лету  шифрует/расшифровывает   данные.   protocol  –  занимается  аутентификацией  клиента  и   сервера  и  коммуникациями  между  ними.   pеrformance  –  тюнинг  под  нагрузку.  
  • 15. Трансляторы   system  –  связывает  хранилище  с  ACL.   sceduler  –  планирует  операции  I/O  для   распределения  новых  записей  по  кластеру.   features  –  доп.  фичи  типа  квот,  фильтров,  локов  и   т.д.   bindings  –  добавляет  расширяемость,  например   есть  реализация  API  для  python.  
  • 16. Падение   1.  Файловая  система  запустит  fsck  на  томе,  далее   gluster  восстановит  данные  из  реплик   автоматически.   2.  В  случае  краха  ноды  добавляем  новую  и  Gluster   размазывает  данные  на  нее.    
  • 17. Гео-­‐репликация   Асинхронная  по  модели  master–slave   Slave  может  быть  как  удаленный  каталог,  так  и   volume  gluster.   Предназначена  для  бекапа,  а  не  для  HA   Периодически  проверяет  изменения  и   синхронизирует  их  инкрементально.  
  • 18. Производительность  
  • 19. Запись  с  sync   4  сервера  2.3ггц,  4гб  ram,  репликация  4х  кратная   Большие  файлы.  8к  –  размер  блока,  как  у  PostgreSQL.   Сеть  150  мбит.     Обьем   Лок.  ФС   GlusterFS   1  гб   434мб/с   18.1мб/с   2  гб   577мб/с   18.6мб/с   4  гб   614мб/с   18.5мб/с   8  гб   733мб/с   17.2мб/с   16  гб   742мб/с   15.1мб/с   В  процессе  использует   30%  cpu,  100%  ram   Для  16гб:   В  процессе  использует   20%  cpu,  85%  ram   Для  1  гб:   1  компонент  использует  макс.  1  ядро
  • 20. Запись  без  sync   4  сервера  2.3ггц,  4гб  ram,  репликация  4х  кратная   Большие  файлы  без  sync.  Сможем  читать  позже  с  диска.   8к  –  размер  блока,  как  у  PostgreSQL.   Сеть  Обьем   Лок.  ФС   GlusterFS   1  гб   613мб/с   18.4мб/с   2  гб   724мб/с   17.4мб/с   4  гб   765мб/с   17.4мб/с   8  гб   737мб/с   18.4мб/с   16  гб   732мб/с   16.3мб/с   В  glusterFS  sync   делается  всегда  
  • 21. Чтение   4  сервера  2.3ггц,  4гб  ram,  репликация  4х  кратная   Сеть  150  мбит.   Обьем   Лок.  ФС   GlusterFS   1  гб   887мб/с   192мб/с   2  гб   602мб/с   204мб/с   4  гб   473мб/с   184мб/с   8  гб   878мб/с   173мб/с   16  гб   887мб/с   185мб/с  
  • 22. Запись  в  лок.  ФС   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   500000   1000000   1500000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 23. Запись  в  gluster  fs   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   100000   200000   300000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 24. Чтение  из  лок.фс.   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   2000000   4000000   6000000   8000000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 25. Чтение  из  glusterfs   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   2000000   4000000   6000000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 26. Случайное  чтение  из  лок.фс.   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   2000000   4000000   6000000   8000000   10000000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 27. Случайное  чтение  из  glusterfs   4  nodes  2.3ghz,  4gb  ram,  4х  rep,   150mbit.   4   128   4096   0   200000   400000   600000   transfer  size  (kb)   File  size  (kb)   kb/s  
  • 28. Рекомендации  от  разработчиков   Работа  через  NFS  быстрее  для  чтения  множества   мелких  файлов.   Работа  через  нативный  клиент  быстрее  для   интенсивной  записи.   https://github.com/gluster/glusterfs/tree/master/doc Дополнительная  информация  по   функционированию:  
  • 29. Ceph   It will not be sufficient that I can - as now - slowly claw my way forward by going through source code, changing scripts, searching for bugs on mailing lists archives. It will be necessary to have an installation process that won't fail. As some problems with Ceph seem to be random, several installs from scratch should be carried out to make sure it's not 2/3 deployments that work.
  • 30. Ceph   •  Потери данных сильно зависят от процесса установки, выбранной ОС, ядра (например система ничего не скажет при работе с 1 mon … до потери данных).   •  Огромное  количество  проблем  при  тестировании  на   разных  ОС  (например  генерация  keyring  на  RedHat).   •  Случайные  падения  во  время  работы.   •  Неочевидный  процесс  восстановления  данных   упавшей  Ceph.   До продакшна далеко…  
  • 31. Архитектура  PCS  
  • 32. PCS   •  от 3 до 5 MDS •  3 или больше CS Рекомендуемая инсталляция на кластер •  Любое кол-во нод в кластере могут играть роли MDS, CS, клиентов •  не требует специализированного оборудования
  • 33. Высокая  доступность  PCS   •  Репликация MDS. До выхода из строя половины MDS гарантируется доступность данных. •  Репликация CS на необходимое количество реплик. •  Мониторит состояние кусков данных и восстанавливает при восстановлении нод. •  возможность мониторинга контрольных сумм CS с SSD кешем журнала CS
  • 34. Расширяемость  PCS   •  Обеспечивается добавлением CS. Протестировано до 1 TB. •  Балансировка IO нагрузки. •  Возможность настройки политик, в зависимости от производительности дисков для выделения.
  • 35. Репликация  PCS   при репликации = 2
  • 36. Деградация  кластера  PCS   при репликации = 2
  • 37. Восстановление  PCS   при репликации = 2
  • 38. Репликация  PCS  vs  Raid   •  Быстрее чем перестроение Raid 1/5/10, т.к. может происходить параллельно по всем серверам кластера. •  Чем больше CS, тем меньше времени на репликацию каждого куска данных. Скорость восстановления важна тк уменьшает вероятность потери данных в деградированном состоянии.
  • 39. Влияние  на  скорость  репликации   •  Количество доступных CS. •  Производительность локальных дисков. •  Производительность локальных дисков. •  Скорость сети: при чтении каждый кусок данных передается по сети для записи доп. копии. •  Распределение кусков данных по CS, которые необходимо реплицировать. •  I/O активность в кластере.
  • 40. Тесты  производительности   репликации  1Тб   Тип   Скорость   Raid1   100  мб/с  (3  часа)   PCS  7  серверов   273  мб/с  (64  мин)   PCS  14  серверов   535  мб/с  (33  мин)   PCS  21  сервер   881  мб/с  (20  мин)   Raid1 7200RPM SATA vs PCS с дисками на 7200RPM SATA SR0
  • 41. Тесты  производительности   репликации  1Тб  на  современном   железе   Тип   1   2   PCS  7   серверов   273  мб/с   649  мб/с   PCS  14   серверов   535  мб/с   1258  мб/с   1) PCS SR0 2SATA 1Gbit Vs 2) PCS SR0 4SATA 10Gbit
  • 42. Горизонтальное  масштабирование   При росте сравнимо с RAID1, добавляя SSD кеш быстрее
  • 43. Горизонтальное  масштабирование   При росте сравнимо с RAID1, добавляя SSD кеш быстрее
  • 44. Вертикальное  масштабирование   PCS использует менее загруженные диски на ноде
  • 45. Вертикальное  масштабирование   PCS использует менее загруженные диски на ноде
  • 46. Выводы  по  PCS   Производительность  PCS  сравнима  с  RAID,  но   предоставляет  большую  гибкость  и  масштабирование.   Репликация  гораздо  быстрее  RAID,  тк  делается   параллельно  между  всеми  серверами  кластера.   Добавление  SSD  кеширования  позволяет  значительно   обогнать  RAID  по  скорости.  
  • 47. Общие  выводы   Gluster  FS  небыстр,  но  может  решить  проблемы   индивидуальных  пользователей  и  малых  компаний.     Ceph  пока  недостаточно  надежен  –  проблемы  с   деплоем  и  падения  при  тестировании.     PCS  готов  для  промышленной  эксплуатации  хостинг-­‐ провайдерами.  Внедрение  в  новой  локации  Tier3   InfoboxCloud  ориентировочно  в  мае  2014.  
  • 48. Спасибо за внимание! Храните данные надежно! Юрий Трухин эксперт по облачным технологиям trukhin.yuri@infoboxcloud.com @trukhinyuri