rivera,
Ознакомтесь
http://forum.oszone.net/announcement-31-75.html
1) Денег сколько?
2) Какая производительность требуется?
3) Какие приложения будут обслуживаться и в каком объеме?
4) Имеющаяся схема сети - чего и куда интегрировать?
=================================================
Цитата rivera:
|
а есть решения с ADSL модемами: firewall со встроенными парочкой-тройкой adsl модемами? »
|
Нет. Причем принципиально. Вы предсталяете как в таком "клубке змей" ошибки искать?
Хотя у cisco было решение "от обратного". В маршрутизатор вставлялись модули SDSL.
Но еще раз повторюсь, ADSL технология
не магистральная , т.е. у нее основные требования это дешевизна порта и высокая плотность.
Мы используем вот это "IES-1000 EE Модульный IP xDSL-коммутатор на 8 - 32 порта"
http://zyxel.ru/content/catalogue/classifier/1/10/30/2
С точки зрения OSI это обыкновенный коммутатор.
=================================================
Цитата rivera:
|
снимает ли наличиет таких фильтров, требование дополнительных программных-прокси серверов »
|
Прокси или кэш? В таких железяках функции кэш нет. Прокси вообще-то тоже.
=================================================
Примеры усторойств, близких по тематике, но немного отличных по сути:
1) Panda GateDefender - защита интернет-шлюза базирующаяся на аппаратном антивирусе
+ антивирус
+ антиспам
+ web - контент
+ возможность отказоустойчивых (кластерных) схем
+ работа в "разрыве" сети на вторм уровне OSI
+ требование лишь к минимальному уровню лицензий (в отличии от програмных решений) т.к. основные деньги фирма берет при продаже железа.
+ Оборудование
реально обладает заявленной производительностью
- встроенного кэша нет
см. приложенный файл
2) Устройства кэширования/акселерации Cisco CSC 11501
Взято тут
http://www.php.com.ua/forum/viewtopic.php?f=26&t=7841
" У меня стоит несколько Cisco CSS 11501 железок. Железки хорошие. Я вообще кошек люблю.
На конкретные вопросы могу ответить.
Пару коментариев по железкам:
Итак, начнём с Level 7 CSS
балансировка загрузки происходит на 7мом уровне ISO/OSI модели. Тоесть на уровне протокола HTTP.
+ куча разной фичурности (если честно, то не нужной).
+ возможность кэширования
+ возможность сжатия на лету
+ изменение исходящего адреса клиента для мервера
- повышенное время ответа как минимум на время 2х TCP/хендшейков + передачи полных двух хидеров.
- при выпадении фронтэнд серверов не слабая задержка.
- медленное изменение параметров балансировки.
- низкая производительность
- работа с ограниченным набором протоколов
Level 4 CSS
+ большое количество поддерживаемых протоколов
+ очень высокая производительность (386 будет работать быстрее core duo xeon 7го уровня)
+ низкая задержка
- слабая возможность администрирования
Level 4+7 CSS
+ задержка - трансвер первой строки хидера + время прохождения 2х пакетов
+ высокая производительность
+ высокая гибкость
- дороговизна решения (от семи килобакксов)
+ возможность стекирования, работы с внешними кэшами и комбинирования с CSS level 7.
Итак одно из решений:
CSS 15501, 4 фронтэнд сервера, сервер БД, и куча суппорт серверов.
софт написсанный с врапером доступа к базе данных, при котором сэлекты выполняются на локальной бд, UpdateDeleteInsert на мастер базе. Репликация мастер слейв. (Слейвы 4ре наших фронтэнд сервера).
По путям /img/* итп форвардинг идёт на ngnx сервера (порт 8081), остальной трафик идёт на апач (возможно поставить squid в режиме аксельрации, но далеко не всегда это целесообразно).
Результат - бутылочное горлышко - затраты на репликацию UDI запросов к бд. Остальное - добавляем новый сервер и получаем прирост производительности в 100/(колво серверов +1)% по сравнению со старой системой. Выбираем хороший метод балансировки (связанно со спецификой трафика) и наслаждаемся жизнью. Попутно имеем многократное повышение надёжности системы. Достаточно просто достичь результатов, когда достаточно работы одного сервера для работы системы в целом (либо с тормозами либо с отсечением блоков адресов). И еще очень много чего о чом лень писать"
