Tigger 20 янв 2011 в 10:29

Массив HP P4000 теперь сможет работать как NAS-сервер

1 мин

3.5K

Блог компании Hewlett Packard Enterprise

Комментарии 11

Smasher 20 янв 2011 в 12:04

То есть по сути это просто сервер с Windows Server без всяких фишечек от leftHand?

Brontozaurus 20 янв 2011 в 15:04

ответил ниже.

osdyng 20 янв 2011 в 12:10

>В нутре HP StorageWorks P4000 Unified NAS Gateway скрывается хорошо известный двухсокетный стоечный сервер HP ProLiant DL360 G7 на базе шестиядерных Intel Xeon 5650. Благодаря этому он обладает гигабитным сетевым адаптером, двумя жесткими дисками и оперативной памятью до 32 Гбайт.

А зачем в NAS шестиядерных Xeon и 32 Гбайта памяти? Это из-за «Windows Storage Server 2008 R2 Enterprise Edition x64»?.. Решения на Linux, на Core 2 Duo и 8 Гбайт, обеспечивают скорость доступа > 200 MB/s. Притом почти вся память, за исключением 200 Мбайт система использует под дисковый кеш, а процессор занять на половину обрабатывать прерывания от сетевой карты.

adontz 20 янв 2011 в 12:48

Я бел на официальном тренинге по P4000. У меня создалось впечатление, что это чистой воды развод. На Linux + GlusteFS + ZFS + LIO можно создать существенно более дешёвое и быстрое решение.

track 21 янв 2011 в 16:20

… но отчего-то не делают :)

adontz 21 янв 2011 в 17:38

Так не умеют просто.

track 22 янв 2011 в 06:38

Всюду заговор против Люникса.

adontz 22 янв 2011 в 13:22

Заговора нет. Есть отсутствие учебных материалов.

Brontozaurus 20 янв 2011 в 15:02

позволю отчасти согласиться с Вами :) да, тот же MSA2000 на двух «Турионах» лопатит весьма и весьма :) т.е. я бы конечно сказал что " мы получаем 12 ядер и до 192 гигабайт памяти( 18 слотов) " но…
тут главное понять, что HP StorageWorks P4000 Unified NAS Gateway это именно NAS Gateway в первую очередь :) то есть это интерфейс к p4000, позволяющий сделать вышеописанный функционал ВМЕСТЕ с HP StorageWorks P4000 SAN

track 21 янв 2011 в 16:23

Человек просто не понимает задачи, которая решается.

Реальная задача для такой системы меряется не в мегабайтах в секунду, а в операциях ввода-вывода в секунду (IOPS) и latency time на random мелкими блоками.
А это совсем другая история.

track 21 янв 2011 в 16:20

В реальной жизни гораздо боле важным параметром быстродействия является не throughput, а latency и IOPS. Нагнать мегабайтов в секунду на секвентальном доступе ума много не надо, но нужны они, по сути, на одной задаче — Backup/Restore.

В жизни же нужны OLTP-like задачи. А это мелкие блоки 4-8K в рандоме, и не объемы трафика, а операции.

И вот это уже гораздо более процессоро- и памяте-емкая задача.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий