Форум о защите от: хакеров, взлом, раскрутка, хакер, вирусы, взлом программы, взлом паролей, взлом вконтакте, взлом icq, раскрутка сайта, взлом скачать, взлом почты, взлом ru, проги взлома, хакер, программа взлома, трояны, программирование

Хакер, взлом, программа, сайт, форум, информатика, железо, разгон, раскрутка, SEO, защита, безопасность, взломать, как взломать, взлом icq, взлом вконтакте, взлом программ, одноклассники, взлом почты, взлом аськи
Текущее время: 02-05, 01:58

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ 1 сообщение ] 
Автор Сообщение
 Заголовок сообщения: Немножко о стерверах
СообщениеДобавлено: 23-09, 14:58 
Не в сети
Starting AH-user

Зарегистрирован: 14-06, 20:52
Сообщения: 12
Отрывок из статьи на
http://securityvulns.ru/articles/xs/filesrv.asp


Часть первая - выбираем платформу.

64 бита бум?

Область оперативной памяти, в которой хранятся данные, полученные с диска, называется в Windows системным кэшем. Чем больше системный кэш, тем реже нам приходится лазить на диск за данными. Мы устраняем необходимость передачи данных с диска в память. Пол дела сделано без каких-либо усилий. 32битное адресное пространство составляет 4GB адресуемой памяти. Именно столько может адресовать любое 32битное приложение, включая и ядро самой системы. В Windows приложение может использовать 2GB (3GB при наличии ключика /3GB в boot.ini, но нас это интересовать совершенно не будет) под свои данные. Из этого следует неприятный факт - для 32битной версии Windows максимальный размер системного кэша составляет 1GB (точнее, даже несколько меньше), что по современным меркам не много. И втыкание в файловый сервер более 2Gb памяти не только не поможет, но и усугубит ситуацию, за счет менее эффективного использования процессорного кэша. Устраняется все это использованием 64 битных платформ. 64 битная версия Windows 2003 поддерживает системный кэш до 1TB. Таким образом, файловый сервер это именно то приложение, в котором использование 64 битной платформы не будет лишним, если мы хотим добиться эффективного кэширования.


Чип и сет спешат на помощь.

Давайте теперь полюбуемся на то, почему нельзя использовать в хорошем файловом сервере десктопные чипсеты, пусть даже очень хорошие и производительные. Посмотрим на примере двух <пограничных> чипсетов по разные стороны границы между сервером и рабочей станцией от Intel. У других производителей дела обстоят аналогично, но у Intel гораздо легче найти нужные картинки. Сравним самый производительный десктопный чипсет 955X (Intel выносит такие чипсеты в отдельную категорию между десктопами и серверами, которую называет "Workstation") и минимальный серверный чипсет начального уровня E7230. Характеристики чипсетов абсолютно идентичны - частоты памяти, пропускные способности шин, поддерживаемые процессоры и схема южного моста.

Вопрос в том, куда мы будем бросать кости, в смысле втыкать оборудование. В 955x скоростная 8-Гигабитная шина PCI Express x16 используется для графики. Для подключения дисковых и сетевых адаптеров мы можем использовать PCI или PCI-X через южный мост (ICH7R). Но производительность шины DMI между южным и северным мосто составляет <всего> 2GB/s, которые будут делиться между диском и сетью. Шина синхронная и здесь гигабайты, а не гигабиты, т.е. скорость вполне приличная, но все же... Серверная платформа имеет дополнительный PCI Hub, обеспечивающий подключение к портам PCI-X через шину PCI Express x8 и порты PCI Express x8 и x4, позволяющие на полную использовать даже 10 гигабитный Ethernet, причем при всем этом дисковая подсистема сможет использовать другую шину. Чем <сервернее> платформа, тем <севернее> располагаются скоростные периферийные шины и тем больше этих шин подключено непосредственно к северному мосту, позволяя с минимальными задержками перемещать данные от внешних устройств к памяти и процессору.

Процессор? Какой процессор?

С одной стороны процессор в файловом сервере всегда остается немного сбоку от основных потоков данных, если сетевой адаптер поддерживает аппаратное вычисление контрольных сумм и сегментацию данных и если, конечно, мы, с дуру, не решили, например, шифровать весь трафик. С другой стороны - он не лишний, потому что каждый пакетик, который мы отправляем в сеть, должен быть сформирован: А пакетик этот не большой, значит их будет много, особенно если сеть, не дай бог, очень производительная, и работа для процессора есть. Кроме того, наш процессор управляет и получает сообщения от различных устройств - сетевых адаптеров, контроллеров дисков. Чем быстрей он эти сообщения обработает, тем лучше. А еще лучше, если сообщения от разных устройств будут обрабатываться параллельно на разных процессорах. Итак, при выборе процессора следует учитывать:

1. Как ни странно это звучит для знатоков параллельных вычислений, лучше два медленных процессора, чем один быстрый, и чем больше различных контроллеров и адаптеров мы имеем, тем больше преимуществ от многопроцессорности мы получим.
2. Чем больше параллельных обращений к памяти (больше системный кэш), тем сильней влияет размер процессорного кэша. Причем кэши двух разных процессоров не суммируются.
3. Много мощных процессоров потребуется, когда мы дойдем до многогигабитной сети.
4. Частота шины процессора может влиять на частоту шины памяти. Поэтому надо выбрать процессор, работающий с частотой шины, не замедляющей работу с памятью.

Сетевая подсистема.

Как мы уже подсчитали, 1 Gb/s (Гигабит в секунду) и 1GB/s (Гигабайт в секунду) - это совсем не одно и тоже. Если мы будем смотреть на гигабитный Ethernet, то реальная скорость передачи за более-менее длительный период времени в нем будет не более 90 MB/s по одному порту из-за асинхронности шины. И, чтобы обслуживать большое количество клиентов, гигабитного Ethernet может быть недостаточно. Первая альтернатива перейти на 10 гигабитный Ethernet, что дорого и не очень стандартно. Особенно это касается адаптеров, способных работать по скоростным версиям PCI-X или PCI Express x4/x8. Подобное решение может окупиться на серверах корпоративного уровня. В качестве более дешевой и менее скоростной альтернативы можно иметь много гигабитных адаптеров. Драйверы многих адаптеров позволяют объединять их в один виртуальный для повышения производительности. Но запомним, что такой режим работы может вызвать недоумение у некоторых коммутаторов (свитчей) и обязательно требует тщательного тестирования. Производительности шины PCI не хватает даже для гигабитного адаптера, с учетом дуплексной передачи, лучше, конечно, использовать PCI Express или PCI- X адаптеры. Не рекомендуется использовать сдвоенные адаптеры. Для Ethernet 10 Gb/s необходимо использовать порты PCI-X 266/533 или PCI Express x4/x8. PCI-X - синхронная шина и реальная ее производительность близка к максимальной 1 GB/s для PCI-X, 2 GB/s для PCI-X 266 и 4 GB/s для PCI-X 533. PCI Express - асинхронная шина и реальная скорость передачи ниже теоретической максимальной. Но идеологически к Ethernet ближе PCI Express.

В большинстве современных адаптеров поддерживаются возможности "TCP Offload" - т.е. перенос вычислительных задач, связанных с организацией сетевого соединения с процессора на сетевую карту. Обычно поддерживается выполнение как минимум двух задач: вычисление контрольных сумм пакета (Checksum Offload) и сегментирование больших пакетов (TCP Segmentation offload, в некоторых драйверах Realtek и HP это называется TCP Large Send Offload). Для производительного сервера на гигабитных скоростях эти задачи критичны, т.к. составляют до 30% всех вычислительных задач сервера из-за того, что весь поток данных пойдет в процессор для вычисления контрольных сумм. Поэтому очень важно, чтобы сетевой адаптер выполнял эти задачи, причем выполнял корректно. В случае, когда необходимо шифрование трафика, сетевой адаптер должен поддерживать и IPSec Offload. Адаптеры с поддержкой IPSec стоят существенно дороже, но даже на них производительность в несколько гигабит останется мечтой.

Дисковая подсистема

Первый вопрос - SCSI или SATA.

Если мы не гонимся в сторону сотен мегабайт в секунду, то сойдет и SATA. Для высокопроизводительных систем, конечно все-таки SCSI. Недостаток решений на шине SCSI - маленькие объемы и высокая стоимость на единицу объема. Но она быстрее. 320 MB/s в Ultra320 SCSI это процентов на 10% быстрее, чем 3 Gb/s в SATA II, опять же из-за фокусов последовательной шины, которой является SATA. Реальная устоявшаяся скорость чтения/записи передовых моделей SCSI дисков так же примерно в полтора раза выше, чем дисков SATA-II, приближаясь к 100 MB/s. Еще одно преимущество дисков SCSI - их гораздо проще набить в большом количестве. Чем больше мы набьем дисков, тем выше будет производительность дисковой подсистемы, т.к. доступ к дискам может осуществляться параллельно. Конечно, имея в распоряжении практически <халявный> SATA, грех им не воспользоваться хоть как-то, например, разместить на нем систему или даже часть данных.

Исходя из приведенных цифр, можно настоятельно порекомендовать использовать двухканальные или четырехканальные SCSI контроллеры и не вешать на канал SCSI более 2-3х дисков. При необходимости иметь более 6 дисков, надо иметь четырехканальный контроллер, использовать несколько контроллеров SCSI или смотреть в сторону более скоростных интерфейсов, таких как Fibre Channel. На сегодня имеется уже достаточное число производительных контроллеров SCSI, например, MegaRAID от LSI с поддержкой PCI Express до x8. Нам вполне хватит PCI-X или PCI Express x4 для хорошо набитого дисками двухканального контроллера, но обычного PCI Express будет маловато. Идеологически SCSI адаптер ближе к PCI-X.

Второй вопрос: какой RAID использовать?

Вопроса, использовать ли RAID для файловых серверов, не стоит. Задачи для RAID в данном случае две - обеспечить отказоустойчивость дисков и максимально повысить быстродействие дисковой подсистемы за счет распараллеливания записи и чтения по дискам. Конечно, самый быстрый RAID - это RAID 0. Однако отказоустойчивостью он не обладает. RAID 5, к сожалению, замедляет операцию записи, особенно при записи небольших кусков данных, но при этом остается весьма быстрым на чтении. Это следствие необходимости пересчитывать и перезаписывать контрольные суммы во время записи неполного блока. Хорошо сбалансированную производительность на чтение и запись имеет RAID 10 (один-ноль), но при этом мы теряем половину емкости дисков. Поэтому, можно порекомендовать RAID 10 для хранения данных, с которыми идет постоянная работа, например, текущих документов, RAID 5 для различных архивов и хранилищ и RAID 0 для временных данных, таких как кэш оптимизирующего прокси-сервера. Естественно, для более качественного распараллеливания, лучше использовать в RAID'е максимальное число дисков и желательно с разных каналов.

Корпус

Ну, а как вы сами думаете, какой нужно иметь корпус, чтобы в него все это:

* Влезло
* Электропиталось
* Не расплавилось

??

Из того, что было сказано выше, сразу прорисовываются два типа файловых серверов. Первый - файловый сервер начального уровня с производительностью до гигабита в секунду, к которому нет практически никаких требований по оборудованию (при условии, что оно достаточно современное) - фактически, можно использовать хорошее десктопное железо с интегрированным SATA RAID 1-0. В мультигигабитном файловом сервере сэкономить не получится ни на чем, стоить он будет на порядки дороже.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ 1 сообщение ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения

Найти:
Перейти:  
cron
Powered by Forumenko © 2006–2014
Русская поддержка phpBB