более 100 терм.сессий 1с с БД 1.5Гб

[Baklan]

хотелось бы узнать о принципиально ином подходе к обеспечению работоспособности такого кол-ва сессий с одной БД (1с 7.7, ДБФ).
вариант с переходом на СКЛ у 7.7 лучше не упоминать
8.0 так же не актуален.
остается одно - терминальчики
имея dual xeon на данный момент все замечательно работает при нагрузке порядка 60 сессий (HT enabled, win2k3, CitrixMFXPFR3)
теперь сам вопрос - можно ли скажем выложить БД на NAS, SAN или скажем вообще iSCSI и плодить вокруг этого хранилища процессорные ёмкости ввиде терм.серверов 9балансируя нагрузку цитриксом и т.д.)
очень актуально так как есть желание вынести БД в ДатаЦентр и расширить кол-во сессий, работающих с одной БД.
очень интересно было бы Ваше мнение - возможно ли вообще подобное решение (некое устройство, которое "шарит" БД ДБФ 1С для терм.серверов, но не средствами MS Networking или же Novell Netware 3.12

[Baklan]

если попытаться поднять старый, добрый SFTIII то можно балансировать сетевую нагрузку - таким образом может и в извращенном варианте, но скажем при организации network teaming (скажем 2 по гбит в каждом из серверов) получается пропускная (теоретическая) пропускная способность пары новелл-серверов на "выдачу" терминальным серверам БД 1С выростает до 4Гбит. безусловно установка скажем RAID10 или RAID50 в каждом из серверов и зеркалирование по MFL (если прально написал аббривеатуру - давно не устанавливал SFT) - купив ГБит адаптеры для этого дела (помню в свое время были оптические

как Вам, гуру, такой безумный вариант?

[a_shats]

Не гуру, но попробую ответить
По первому вопросу:
Да, конечно, возможно. но: нужно, чтобы это был именно сетевой том (где лежит база) - для терминальных серверов. Есть, теоретически, софтовые решения типа SANbolic Melio FS, позволяющие с нескольких серверов безопасно работать с томом на внешнем сторадже, как локальным, но в данном конкретном случае это - имхо - не подходит: у 1С свои блокировки, у Melio - свои, да и тормоза будут...
Мне решение видится примерно так: несколько терминальных серверов (не менее 2, а, скорее 3-4 в Вашем случае), сидящих на гигабитном коммутаторе с SCSI NAS или сервер+внешний сторадж, что, по сути, то же самое. Понятно, что чем шустрее канал до NAS, тем лучше это будет работать...

[Baklan]

я преднамеренно не акцентировал внимание именно на NAS так как понимал, что даже пусть там стоит Windows Embedded Storage edition (могу ошибаться в самом названии, но суть ясна - заточенный майкрософтом 2003 сервер под файловый сервис) все-равно фактически это обычный сервер с "шарой" в сети. конечно всякого рода network teaming до гбит свича этого NAS может как-то облегчить жизнь, НО как показывала практика при объеме БД 1С 500Мб и активных 30 сессиях (два свича 24*100, 1Гбит) шел такой пакетный шторм что становилось страшно - переход по позициям в накладной вызывал шторм с рабочей станции порядка 15к пакетов в сек! (данный перф.монитора на этой же раб.станции). как итог - применение шаринга по TCP/IP-netbios и т.д. может снова очень печально закончится и узким местом здесь будет сама убогость работы 1С с удаленной БД. поэтому предпочтительнее нестандартный вариант - iSCSI, NAS, SFTIII от новеля
кстати - а не попробовать ли NETBEUI как протокол работы с псевдо NAS-устройством?

[a_shats]

На NAS обычно ставят либо свой вариант Линукса, либо Windows 2000/2003 Server+Windows 2000/2003 Appliance Kit
А проблема, на самом деле, одна: расшариваемая между серверами (не по LAN, а по SAN )файловая система: MFT у NTFS кэшируется в ОЗУ каждого из серверов, и "не знает" о SAN - что они натворят на расшаренном томе NTFS вместе - просто подумть страшно .
С другой стороны, мы тестировали Melio FS www.sanbolic.spb.ru - именно на такой задаче (много потоков и random доступ) она проседала по производительности в добрых 3 раза . Т.е. не подойдет.
С другими подобными вещами в этом плане еще хуже - ну не затачивались оне изначально под БД...
А тиминг в данной ситуации спасет, ибо пакеты будут ходить вагонами только между NAS и терминальными серверами...
Имхо.

[gs]

Вчера общался с одним толковым мужиком из франчайзи 1С. Они применяют решение банально тупое - файловый сервер под Новелл (из-за умного кэша) и несколько терминальников. Связь - пачка гигабиток. Утверждает, что это вполне работает при базе 3ГБ и 150 юзеров. В принципе я ему верю - какой ему смысл меня грузить?

Кстати, проверьте перфмоном нагрузку на дисковую систему (самый показательный параметр - очередь команд). Беда 1С - блокировка регистров. Ее можно вылечить установкой рэйд контроллера типа LSI 320-2X с гигабайтом кэша. Чтобы кэш на запись проглатывал блокировки.

[gs]

А по поводу применения систем расшаривания диска на несколько машин при помощи SAN - Шац прав, при массе мелких запросов все системы такого плана (Sanbolic MelioFS, Tivoli SANergy...) жутко тормозят из-за работы собственного механизма блокировок (причем тут блокировки не на уровне записей базы, как в Oracle RAC, а на уровне блоков диска, т.е. намного хуже).

[Baklan]

есть ли где-нить возможность посмотреть таблицу-матрицу по производительности NASов?
Ваше мнение - будет ли NAS (windows-based) работать эффективнее, нежели Netware Server (не NAS, а просто сервер)?
то же самое и к Линукс-based NAS.
КТО БЫСТРЕЕ ОТДАСТ БД В СЕТЬ?

[gs]

NAS - это и есть банальный файл-сервер Только красиво обозванный и с прикрученной консолью управления.
И с новелом по этой части еще никто имхо не сравнился.