GFS2 один писатель несколько читателей настройки

Мне бы хотелось получить ваш совет по настройке, которую я внедряю, чтобы несколько хостов могли совместно использовать разные данные в общем хранилище iSCSI. Я использую GFS2 для совместного доступа к логическому тому LVM2 на iSCSI, и я бы предпочел избежать сложности настройки кластера с помощью CoroSync и т. Д.

Я отформатировал файловую систему с блокировкой, равной lock_nolock, и одним журналом. Отдельному узлу будет поручено выполнение периодических обновлений, которые обычно включают в себя копирование новых файлов в том, но без изменений существующих, и все другие узлы будут монтировать его как зрителя, ro. Согласно справочной странице это будет:

Смонтируйте эту файловую систему, используя специальную форму монтирования только для чтения. Монтирование не использует один из журналов файловой системы. Узлу не удалось восстановить журналы для других узлов.

Могу ли я разумно ожидать, что эта установка будет стабильной и производительной? Любые ошибки, на которые я должен обратить внимание?

Можно ли предположить, что попытка монтировать R/W с нескольких хостов не удастся, поскольку файловая система имеет только один журнал?

Источник

1 ответ

Решение

Я реализовал вышеописанную настройку, и она отлично работает с одним основным ограничением: хосты, монтирующие R/O, не могут знать, что общий том изменился. После выполнения обновлений с хоста, у которого есть доступ для записи, мне нужно вручную синхронизировать файловую систему и затем заставить читающих клиентов очищать свои буферы inode с помощью такой команды, как echo -n 2 | sudo -n /bin/dd of=/proc/sys/vm/drop_caches, Обратите внимание, что если содержимое файла может измениться, вам нужно написать 3 вместо 2, чтобы также очистить файлы.

Другая проблема, с которой я иногда сталкиваюсь, заключается в том, что клиенты R/O могут не смонтировать общее хранилище с "отказано в доступе". Чтобы решить эту проблему, мне нужно отключить том от узла R/W, смонтировать на всех узлах R/O, которые испытывают проблему, а затем снова подключить на узле R/W.

Ниже приводится роль Ansible, которая выполняет это:

---
- name: Determine the canonical path of the shared-data directory
set_fact:
    shared_dir_real_path: "{{ shared_dir_path | realpath }}"

- debug:
    msg: "Manually forcing flushing and re-read of directories on volume at {{ shared_dir_path }} (real path: {{ shared_dir_real_path }})."
    verbosity: 1

- name: Determine shared-dir mount point
command: "/usr/bin/env stat -c '%m' {{ shared_dir_real_path }}"
register: shared_dir_mount_point
changed_when: False

- name: Determine the mount point's filesystem type and mount options
set_fact:
    "shared_dir_mount_{{ item }}": "{{ ansible_mounts | selectattr('mount', 'equalto', shared_dir_mount_point.stdout) | map(attribute = item) | join(',') }}"
with_items:
    - fstype
    - options

- name: Verify the shared-dir is mounted GFS2
assert:
    that: "'{{ shared_dir_mount_fstype }}' == 'gfs2'"

- name: Determine the access to the shared-data directory
set_fact:
    shared_dir_access_flags: "{{ ['ro', 'rw']  | intersect( shared_dir_mount_options.split(',') )}}"

- name: Verify Access mode sanity
assert:
    that: shared_dir_access_flags | length == 1

- name: Sync the shared filesystem
command: "sudo -n /bin/sync -f {{ shared_dir_real_path }}"
args:
  warn: false # Silence warning about the use of sude instead of 'become', which is here deliberate

when: "'rw' in shared_dir_access_flags"

- name: Force re-load of directory inodes
shell: "echo -n 2 | sudo -n /bin/dd of=/proc/sys/vm/drop_caches"
when: "'ro' in shared_dir_access_flags"
Источник
Другие вопросы по тегам