И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Каждый сервер где-то 250т.р. (с дисками)
Коммутаторы по ~150т.р. Но от них для этой задачи вообще ничего кроме VLAN не требуется, так что подойдут любые гигабитные управляемые.
Я режим master-master не использую принципиально — производительности single-master мне более чем достаточно, а сохранность данных у меня на первом месте.
По поводу протокола B и dual-primary в доках DRBD чётко написано:
Dual-primary mode requires that the resource is configured to replicate synchronously (protocol C).
1. Я mdraid в продакшене не использую особо, только дома, так что видать чаша сия меня обошла. Баги то они везде бывают, тут вопросов нет, другое дело, что тобы они вылезли зачастую нужно чтобы звезды сошлись правильным образом. У меня система, подобная описаной в статье, работает уже пару лет под 24х7 нагрузкой (пусть и не стрессовой) — всё ровно.
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
С отключеным вещанием SSID бывают глюки у разных девайсов, да и батарейка, возможно, будет разряжаться быстрее т.к. телефон тот же будет периодически пытаться подключиться к невидимой сети.
Конечно, производитель должен был обеспечить нормальный образ восстановления, загрузившись с которого и нажав одну кнопку я бы получил работающий контроллер.
И у них это почти получилось :) Непонятно только зачем образ восстановления пытается шить в обычном режиме, а не в Mode0, ну и косяк с виртуальным приводом CDROM, который во всех остальных местах работает ОК.
Опция -a указывает какие контроллеры шить, например -a0,1 или -aALL, а вот уже в режиме восстановления (Mode0) этой опции вообще нет.
Ну, завод это еще нормально, у меня отец в ВТБ24 работает, там до сих пор очень большая часть бановского софта под DOS-ом крутится, еще на FoxPro или чем-то подобном писанного.
Да, лет 5-7 назад я покупал Адаптеки, но с ними у меня как-то не сложилось.
Один из контроллеров (52445, огромный такой, на 28 портов, бешеных денег стоил) у меня первые пару лет работы периодически глючил — то сам контроллер в резет уходит, то винты с него отваливаются с большим кол-вом I/O ошибок, хотя они здоровые (это решилось обновлением прошивки самих винтов, хотя с другими контроллерами они не глючили), то еще какая-то напасть. Он до сих пор трудится и после крайнего обновления прошивки вроде как успокоился глючить и работает ровно :)
А про Smart Array вообще лучше говорить не буду, один тот факт, что для настройки контроллера и создания массивов (кроме самых простых режимов) — то нужно загрузиться с HP Smart Start, нормальный BIOS компания HP не осилила.
Опять таки — это если changelog доступен, что бывает совсем не всегда, особенно с биосами и прошивками.
В опенсурсе с этим всё попроще, можно просто посмотреть коммиты в GIT :) и решить — ставить или нет — обычно просто.
Так что если ченджлога нет — я обычно обновляю, за 10 лет работы еще не пожалел об этом.
Может я старомоден, но люблю когда под боком своя серверная и своё железо.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Просто LSI, в отличии от многих других компаний, предоставляет достаточно подробные Changelog-и, где можно четко увидеть что было исправлено в очередной версии прошивки. И местами там такое встречается, что может в определенных обстоятельствах привести к потере данных. Так что я стараюсь себя обезопасить заранее купировав возможные проблемы.
Судя по моей практике ситуации подобные этой встречаются крайне редко и, как видно, решаются достаточно просто, если знаешь что делать :)
Те же BIOS-ы в материнках Supermicro можно аналогично восстановить после неудачного обновления используя простую флешку в FAT, файлом биоса на ней под именем SUPER.ROM и зажатых клавиш Ctrl+Home при запуске сервера. Мне пока делать этого не приходилось, но на заметке держу…
Так что я голосую за обновление, если есть возможность и особенно если есть список изменений.
И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Так что нет, для себя смысла не вижу.
Коммутаторы по ~150т.р. Но от них для этой задачи вообще ничего кроме VLAN не требуется, так что подойдут любые гигабитные управляемые.
По поводу протокола B и dual-primary в доках DRBD чётко написано:
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
И у них это почти получилось :) Непонятно только зачем образ восстановления пытается шить в обычном режиме, а не в Mode0, ну и косяк с виртуальным приводом CDROM, который во всех остальных местах работает ОК.
Опция -a указывает какие контроллеры шить, например -a0,1 или -aALL, а вот уже в режиме восстановления (Mode0) этой опции вообще нет.
Один из контроллеров (52445, огромный такой, на 28 портов, бешеных денег стоил) у меня первые пару лет работы периодически глючил — то сам контроллер в резет уходит, то винты с него отваливаются с большим кол-вом I/O ошибок, хотя они здоровые (это решилось обновлением прошивки самих винтов, хотя с другими контроллерами они не глючили), то еще какая-то напасть. Он до сих пор трудится и после крайнего обновления прошивки вроде как успокоился глючить и работает ровно :)
А про Smart Array вообще лучше говорить не буду, один тот факт, что для настройки контроллера и создания массивов (кроме самых простых режимов) — то нужно загрузиться с HP Smart Start, нормальный BIOS компания HP не осилила.
В опенсурсе с этим всё попроще, можно просто посмотреть коммиты в GIT :) и решить — ставить или нет — обычно просто.
Так что если ченджлога нет — я обычно обновляю, за 10 лет работы еще не пожалел об этом.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Но из принципа захотелось его побороть :)
Просто LSI, в отличии от многих других компаний, предоставляет достаточно подробные Changelog-и, где можно четко увидеть что было исправлено в очередной версии прошивки. И местами там такое встречается, что может в определенных обстоятельствах привести к потере данных. Так что я стараюсь себя обезопасить заранее купировав возможные проблемы.
Судя по моей практике ситуации подобные этой встречаются крайне редко и, как видно, решаются достаточно просто, если знаешь что делать :)
Те же BIOS-ы в материнках Supermicro можно аналогично восстановить после неудачного обновления используя простую флешку в FAT, файлом биоса на ней под именем SUPER.ROM и зажатых клавиш Ctrl+Home при запуске сервера. Мне пока делать этого не приходилось, но на заметке держу…
Так что я голосую за обновление, если есть возможность и особенно если есть список изменений.