Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] Re: [uanog] [Q] Отказоустойчивость для LAN

On Thu, Oct 07, 2010 at 09:33:04AM +0300, Vladimir Litovka wrote:

2010/10/7 Paul Arakelyan Реализовать и гарантировать - всё же разные вещи. Банальный read retry

...

SATA HDD/DVD, например, поставит раком половину ОС (Solaris с raidz2, в котором диск с 1400 ремапов порой конкретно тупит - похоже, диск в PIO mode слетает, хотя zpool status ничего плохого не показывает).

Т.е. гарантировать "почти можно" на определённом наборе железа и софта - реализуемо в очень ограниченных масштабах.

Паша, спасибо, исчерпывающий ответ.

То есть можно сказать, что если сервер не укомплектован периферией (вплоть до netboot в RAM), то шансы успешно реализовать на нем OSPF fast convergence существенно возрастают - это так?

Да, если на нём ещё и не исполняется "хз что" впридачу. (Можно надеяться на шедулер, но в том же солярисе - чтение-запись с gzip'ed ZFS вгоняет в ступор 2 ядра запросто, с пингами как на луну, 4 - не помню, но тоже вполне загружаемо кажется. Мультимедиа при этом ваще лесом идёт). У меня есть "ХЗ что" - графики mrtg/rrdtool ;). Ещё "втуляние маршрутов в таблицы маршрутизации" - тоже процесс... И VPN там же, с компрессией :).Короче, нужен "controlled environment". Или костыли всякие, типа "проверим не пришло ли чего посреди пересчёта таблицы" (потоки наверно не совсем хорошо - ими шедулер рулит же). -- Best regards, Paul Arakelyan.