Я хотел бы получить ваш совет по настройке, которую я реализую, чтобы позволить нескольким хостам совместно использовать иногда разные данные в общем хранилище iSCSI. Я использую GFS2 для совместного доступа к логическому тому LVM2 на iSCSI, и я бы предпочел избежать сложности настройки кластера с помощью CoroSync и т. Д.
Я отформатировал файловую систему, установив блокировку на lock_nolock и единый журнал. Одному узлу будет поручено выполнять периодические обновления, которые обычно включают в себя копирование новых файлов в том, но без изменений существующих, а все остальные узлы будут монтировать его как зритель, ro. Согласно странице руководства это будет:
Смонтируйте эту файловую систему с помощью специальной формы монтирования только для чтения. При монтировании не используется ни один из журналов файловой системы. Узел не может восстановить журналы для других узлов.
Можно ли ожидать, что эта установка будет стабильной и производительной? Есть ли ошибки, на которые я должен обратить внимание?
Могу ли я предположить, что попытка смонтировать R / W с нескольких хостов потерпит неудачу, поскольку файловая система имеет только один журнал?
Я реализовал описанную выше настройку, и она отлично работает с одним серьезным ограничением: хосты, которые монтируют R / O, не имеют возможности узнать, что общий том изменился. После выполнения обновлений с хоста, у которого есть доступ для записи, мне нужно вручную синхронизировать файловую систему, а затем заставить читающих клиентов очистить свои буферы inode с помощью такой команды, как echo -n 2 | sudo -n /bin/dd of=/proc/sys/vm/drop_caches. Обратите внимание: если содержимое файла может измениться, вам нужно написать 3 вместо 2, чтобы также очистить файлы.
Другая проблема, с которой я иногда сталкиваюсь, заключается в том, что клиенты R / O могут не смонтировать общее хранилище с «отказом в разрешении». Чтобы решить эту проблему, мне нужно размонтировать том с узла чтения / записи, смонтировать на всех узлах R / O, на которых возникла проблема, а затем снова смонтировать на узле чтения / записи.
Ниже приведена роль 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"