хорошо, часы — это условность, но если все перейдут на одно время, то в некоторых зонах смена даты будет посреди дня. Например, рабочее время с 21:00 до 6:00, получается, что через 3 часа после начала рабочего времени происходит смена даты, и это будет больше запутывать людей, и соответственно провоцировать больше ошибок.
Полностью согласен, кроме того, лично встречал сетевые карты, которые работали только при соединении cross-over кабелем (сетевухи на 100mbit) правда, это было давно. Авто-согласование обычно работает только на 1Gbit картах, т.к. в них все пары одновременно RX/TX.
atop — без графиков, но показывает много информации, включая IO по процессам и позволяет вести лог процессов и потребления ими ресурсов с заданной периодичностью
большинство RAID контроллеров поддерживает UNMAP, с которого скопирован TRIM. Кроме того ZFS рекомендуют использовать не с RAID контроллерами а с HBA, т.к. у последних задержки ниже, а функциональность первых не востребована.
во втором примере, если небольшая компания, с ИТ отделом в пару человек, возможна ситуация, что при аварии специалисты не смогут отреагировать за 2-8 часов в нерабочее время, в силу обстоятельств. поэтому может и стоит настроить резервирование в минимальном варианте.
Есть вариант решения этой проблемы: LACP предполагает возможность балансировки по MAC, IP, Port:
XOR (balance-xor)
Transmit network packets based on a hash of the packet's source and destination. The default algorithm only considers MAC addresses (layer2). Newer versions allow selection of additional policies based on IP addresses (layer2+3) and TCP/UDP port numbers (layer3+4). This selects the same NIC slave for each destination MAC address, IP address, or IP address and port combination, respectively. This mode provides load balancing and fault tolerance.
т.е. если два хоста передают данные больше чем по одному коннекту (IP:port <-> IP:port) — то суммарная скорость должна превышать скорость одного линка.
Cisco, по крайней мере в некоторых моделях комутаторов, это поддерживает:
You can base the load-balance policy (frame distribution) on a MAC address (Layer 2 [L2]), an IP address (Layer 3 [L3]), or a port number (Layer 4 [L4]). You can activate these policies, respectively, if you issue the set port channel all distribution {ip | mac| session | ip-vlan-session} [source | destination | both] command.
Вот старый тест на Atom 330 с 2GB RAM: http://www.phoronix.com/scan.php?page=article&item=kq_zfs_gold&num=1
Да, звёзд с неба не хватает… Учтите, реализация ZFS в Linux не самая быстрая, и думаю, что настройки по умолчанию тоже могут быть не лучшие…
Если приведете исследования в сравнении с каким-нибудь 5-6 рейдами, буду благодарен. И именно в аварийных условиях.
Исследований не приведу, но есть личный опыт. Аппаратные RAID при ошибках на соответственно двух или трёх дисках приводят к полной потере информации в масиве, в ZFS, при правильном подходе возможно восстановить или большую часть информации, или даже всю.
В ZFS наиболее правильная замена диска — это не отключая вышедший из строя (при условии что он определяется и с него можно получить хотя-бы часть данных) подключить новый диск и выполнить zpool replace. В случае ошибок на других дисках RAID группы, ZFS умеет взять часть данных с заменяемого диска, т.к. ZFS по умолчанию хранит контрольные суммы данных — то по этой информации система может определить на каких дисках она находиться в не поврежденном виде, и может её восстановить при множественных ошибках дисков. При использовании RAID 5/6 в такой ситуации дорга или к специалистам по восстановлению данных, или самому становиться таким специалистом.
Рекомендация: для избежания множественных проблем с дисками, периодически (раз в 1--6 недель) читать все данные с дискового массива. Для ZFS — это scrub, для остальных подойдет dd if=/dev/md* of=/dev/null, для владельцев хороших RAID контроллеров — включить patrol read.
Я бы предпочел два сборных из хлама NAS в разных местах с бекапом с одного на другой, чем один более крутой NAS с правильной памятью, дисками и т.д. :)
Правильная мысль, только копировать данные на них надо из одного «надёжного» источника, что-бы ишибки памяти, дисков, контроллера, процессора, сетевой карты и т.д. не испортили данные…
Если у вас важные данные — то сохраняйте резервную копию на LTO или на HDD, который храниться в отключённом состоянии, т.к. если электрики перепутают провода, и в розетке будет 380В — то есть вероятнось, что сгорят все жесткие диски разом. Если идти дальше — то резервную копию необходимо держать ув другом здании, а желательно — в нескольких других городах, с расстоянием более 1000км друг от друга…
Я не спорю, что для NAS лучше использовать серверное железо высокого качества и надёжности, хотя и с таким железом бывают проблемы (помниться были проблемы с RAID контроллерами LSI 94240-4I на 4TB дисках с какими-то версиями прошивки, и если-бы не ZFS — то источник проблемы искали-бы намного дольше). Но совокупная стоимость системы с ECC выше, и каждый пусть решает сам, стоять ли его данные столько — что оправдана более высокая стоимость системы с ECC…
Не вижу причин отказываться от ZFS, по моему опыту — производительность у mdraid хуже, правильные аппаратные решения для дома — дорого выходят…
В ZFS контрольные суммы отключаются одной командой, скраб — штука очень полезная, умный аналог patrol read на хороших RAID контроллерах. Решения, предназначеные для долгой работы 24/7 без обслуживания — это совсем другой клас устройств, а минимальное оповещение об проблемах несложно организовать, чего должно быть достаточно для домашнего применения.
Для ZFS не обязательно много памяти, все зависит от необходимой скорости, например знаю реальный сценарий использования ZFS на массиве примерным объемом 180TB с памятью 32GB, хотя рекомендовано 1GB на 1TB, но для архивного хранилища — более чем достаточно, скорость до 600MB/s.
Не встречал контроллеров LSI без утилит для Linux, и драйвера всегда были. Единственное — есть проблема с поиском утилит в DEB пакетах (но они есть). Ну и консольные команды придумывали чужие для хищников.
Полностью согласен, кроме того, лично встречал сетевые карты, которые работали только при соединении cross-over кабелем (сетевухи на 100mbit) правда, это было давно. Авто-согласование обычно работает только на 1Gbit картах, т.к. в них все пары одновременно RX/TX.
IMHO: Интересная работа не приводит к выгоранию
т.е. если два хоста передают данные больше чем по одному коннекту (IP:port <-> IP:port) — то суммарная скорость должна превышать скорость одного линка.
Cisco, по крайней мере в некоторых моделях комутаторов, это поддерживает:
пруф
Да, звёзд с неба не хватает… Учтите, реализация ZFS в Linux не самая быстрая, и думаю, что настройки по умолчанию тоже могут быть не лучшие…
Исследований не приведу, но есть личный опыт. Аппаратные RAID при ошибках на соответственно двух или трёх дисках приводят к полной потере информации в масиве, в ZFS, при правильном подходе возможно восстановить или большую часть информации, или даже всю.
В ZFS наиболее правильная замена диска — это не отключая вышедший из строя (при условии что он определяется и с него можно получить хотя-бы часть данных) подключить новый диск и выполнить zpool replace. В случае ошибок на других дисках RAID группы, ZFS умеет взять часть данных с заменяемого диска, т.к. ZFS по умолчанию хранит контрольные суммы данных — то по этой информации система может определить на каких дисках она находиться в не поврежденном виде, и может её восстановить при множественных ошибках дисков. При использовании RAID 5/6 в такой ситуации дорга или к специалистам по восстановлению данных, или самому становиться таким специалистом.
Рекомендация: для избежания множественных проблем с дисками, периодически (раз в 1--6 недель) читать все данные с дискового массива. Для ZFS — это scrub, для остальных подойдет dd if=/dev/md* of=/dev/null, для владельцев хороших RAID контроллеров — включить patrol read.
Правильная мысль, только копировать данные на них надо из одного «надёжного» источника, что-бы ишибки памяти, дисков, контроллера, процессора, сетевой карты и т.д. не испортили данные…
Я не спорю, что для NAS лучше использовать серверное железо высокого качества и надёжности, хотя и с таким железом бывают проблемы (помниться были проблемы с RAID контроллерами LSI 94240-4I на 4TB дисках с какими-то версиями прошивки, и если-бы не ZFS — то источник проблемы искали-бы намного дольше). Но совокупная стоимость системы с ECC выше, и каждый пусть решает сам, стоять ли его данные столько — что оправдана более высокая стоимость системы с ECC…
В ZFS контрольные суммы отключаются одной командой, скраб — штука очень полезная, умный аналог patrol read на хороших RAID контроллерах. Решения, предназначеные для долгой работы 24/7 без обслуживания — это совсем другой клас устройств, а минимальное оповещение об проблемах несложно организовать, чего должно быть достаточно для домашнего применения.