Ще до свят колега Virus хотів розповісти нам цю історію, але через технічні причини публікація затримувалася 🙂
Йтиметься про те, як зробити з 1 комп'ютера і двох дешевих гігабітних світчей «D-Link DGS-1005D» дисковий типу «масив», застрахувавши від найбільш ймовірних аварій - загибелі диска і загибелі блоку живлення дешевого світча. Наявність швидкого і дешевого D-Link дозволить для робочого трафіку використовувати повільні і дешеві 100mbit Cisco Catalyst з підтримкою vlan і інших радощів життя, а для міграції та доступу до «масиву» дешеві D-Link. Звичайно, ви не будете застраховані від вигорання материнок, БП чи інших запчастин в цьому «масиві». Втім, ця проблема вирішувана, але вона виходить за рамки даної статті точно так же, як і використання FC карт замість ethernet або завантаження з usb-flash. Хоча всі ці теми дуже цікаві, і швидше за все будуть мною описані, після того як «сервер» з коренем на флешках відпрацює пару місяців, я розповім про нього і ще кілька згаданих збочень.
Також варто пам'ятати, що якщо у вас буде корінь на рейді, то ви обмежені тільки першим рейдом + старим форматом метаданих + швидкістю одного диска, тобто в разі якщо є 3 або більше диска, то оптимально для кореня використовувати пару флешок, об'єднаних в рейд -1, а решта використовувати у вигляді raid5 (в силу ряду очевидних причин з софт-raid5 завантажитися не можна).
Спершу з'єднаємо кожен свитч з кожним комп'ютером (iSCSI + 2ESXi), встановимо систему (gentoo linux) і пропишемо конфіги:
/etc/modprobe.d/bond.conf
alias bond0 bonding
options bond0 mode = 0 miimon = 100
# Нижче опис параметрів, можливо вам стане в нагоді:
# Arp_interval: arp interval in milliseconds (int)
# Arp_ip_target: arp targets in n.n.n.n form (array of charp)
# Arp_validate: validate src / dst of ARP probes: none (default), active,
backup or all (charp)
# Downdelay: Delay before considering link down, in milliseconds (int)
# Lacp_rate: LACPDU tx rate to request from 802.3ad partner (slow / fast) (charp)
# Max_bonds: Max number of bonded devices (int)
# Miimon: Link check interval in milliseconds (int)
# Mode: Mode of operation. 0 for balance-rr, 1 for active-backup, 2
for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6
for balance-alb (charp)
# Primary: Primary network device to use (charp)
# Updelay: Delay before considering link up, in milliseconds (int)
# Use_carrier: Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for
off, 1 for on (default) (int)
# Xmit_hash_policy: XOR hashing method: 0 for layer 2 (default), 1 for
layer 3 + 4 (charp)
/etc/conf.d/network
ifconfig_eth1 = »10.2.123.44 netmask 255.255.255.0"
defaultroute = »gw 10.2.123.254"
interfaces = »bond0"
ifup_bond0 = »modprobe bonding; ifconfig \ $ int up; ifenslave \ $ int eth2;
ifenslave \ $ int eth3 "
ifconfig_bond0 = »10.2.254.1 netmask 255.255.255.0"
ifdown_bond0 = »rmmod bonding»
Створена бітмапами, щоб рейд збирати заново швидше в разі аварій, ключове значення «131072». Чим більше шматки, які контролюються, і отже тим менше паразитная навантаження на диски (і очевидно менше гальмує), але тим довше буде синхронізація, так як більшого розміру шматки (це 128Мб, можна робити шматки до 256).
Тепер йдемо в «storage adapters» включаємо iscsi адаптер і прописуємо
наші логін і пароль в «Dynamic discovery» -> »CHAP» (якщо забули це
esxiuser і secur789)
Після цього все повинно з'явитися і працювати.
PS: Чому не варто використовувати RAID1. Як не дивно, виявилося що
RAID1 (що факерейд, що Софтрейд) не вміє балансувати навантаження по
читання (хоча є ймовірність що я не знайшов будь-нитка особливо-таємницею
ручки в Софтрейд щоб цей режим включити) RAID5 як не дивно
балансує читання відразу «з коробки».
PPS: при проблемах на одному з дисків - запис йде на швидкості самого
повільного (читай збійного) диска і виходить швидкість дуже погана.
якщо у нас RAID5 і один диск посипався, то raid контролер викреслює його зі списку живих і перетворюється в RAID 0
якщо є хот СПАР то починається ребілд, АЛЕ якщо під час ребілд вийде з ладу (хоча б 1 bad) ще один диск то все raid контролер відключить весь масив.
в ZFS усвідомили що диск вмирає - вставили ще один (або був призначений нот СПАР)
при читанні ZFS не може прочитати шматок - відновлює його по надмірності і пише на новий диск - в RAIDZ можна тягнути інфу з масиву де все диски биті (з bad блоками, але електроніка працює) причому консольної командою можна отримати список файлів які ZFS не зміг відновити .
у випадку з RAID 5 контролер просто не знає - що там на диску.
плюс захист від фантомної записи, від проблем з кабелями і контактами, тк дані і контрольна сума зберігаються в різних місцях.
В якості альтернативи, можна запропонувати пару цілком гідних рішень де є реалізація ZFS, вбудований необхідний мінімум для організації стораджа, простота і швидкість установки / налаштування / відновлення:
1. FreeNAS
2. NexentaStor Community Edition (обмеження до 6Tb дискового простору)
У FreeNAS дійсно зустрічаються криві збірки, з тими чи іншими косяками в різних модулях. Це одне з основних відмінностей stable релізів від nightly 😉 Крім того, гілки 0.7 і 8 мають ряд технічних відмінностей, на що також варто звертати увагу.
У самого в продакшені близько двох років на різних майданчиках стабільно працюють 5 сховищ (iSCSI, NFS, CIFS). Використовуються виключно stable збірки.
NexentaStor - готове софт-рішення для організації стораджа (iSCSI, NAS, CIFS) на основі Solaris. Простий в установці. Налаштування через web-морду. Все просто і досить зрозуміло. Для отримання кращого по продуктивності результату настійно рекомендується почитати best practics.
Обидва рішення, перш за все, цікаві своєю готовністю для більшості випадків, простотою настройки «з коробки», простотою відновлення працездатності сховища після аварії або зміни заліза, простотою організації резервування за все стораджа або його частини (Rsync).