Author Archive

Data ONTAP Simulator 8.0.1: Как изменить SystemID/SerialNo?

В ряде случаев, например когда вы планируете использовать несколько установленных симуляторов, подключенных в Operations Manager, необходимо задать каждому из этих симуляторов индивидуальный SystemID и Serial Number. В будущем в NetApp обещают генерировать при установке произвольный номер, а пока все симуляторы идут с одним. Поэтому нужно проделать небольшой трюк.

При начальной загрузке прервите ее и войдите в SIMLOADER.

sim801_serial_change_1

sim801_serial_change_2

Выполните там две следующие команды:

SIMLOADER> set bootarg.nvram.sysid=1111111101
SIMLOADER> set SYS_SERIAL_NUM=1111111101

sim801_serial_change_3

SystemID это 10-значное число. Последние две цифры должны быть уникальны в пределах Cluster-mode кластера для того, чтобы обеспечить уникальность UID дисков. Таким образом первые 8 цифр определяют кластер, а последние 2 – ноду в этом кластере. Впрочем, если вы используете симулятор только как 7-mode, вам это не важно, назначьте туда любое 10-циферное число.

Дайте команду:

SIMLOADER> boot

sim801_serial_change_4

Войдите в Boot Menu нажатием Ctrl-C и выберите там Maintenance mode boot

sim801_serial_change_6

Переназначьте диски на новый SystemID, если вы уже назначили их ранее контроллеру на его прежний SystemID. Если вы делаете описываемую процедуру при самом первом старте, то переназначать диски еще не нужно, назначьте из обычным образом.

sim801_serial_change_7

UPD: Приведенный метод, к сожалению, НЕ РАБОТАЕТ для Simulator версии 8.1, он работает только для 8.0.1

NDMPCOPY

Несмотря на то, что протокол NDMP, о котором я тут уже, было дело, пару раз рассказывал, и не слишком популярен, да и вообще стагнирует, он, даже в имеющемся виде, может быть полезен и интересен.

Например с помощью встроенной в Data ONTAP команды ndmpcopy можно внутренними средствами контроллеров системы хранения копировать данные как внутри одной системы хранения, так и между ними (то есть не гоняя их “через внешний хост”, а непосредствено с контроллера на контроллер). Иногда это бывает очень удобно. Некоторое время назад я показывал использование ndmpcopy для переноса root volume системы хранения, там мы копировали по ndmp содержимое root vol на новый том, который потом делали новым root.

К сожалению, существующая на сайте ndmp.org программа ndmpcopy отличается по функциональности от встроенной в DOT, не умеет междевайсное копирование, и работает со старой версией протокола, что значтельно сужает область ее использования.

Однако доброволец-энтузиаст недавно переписал ndmpcopy на java, реализовал NDMPv4, и ряд дополнительных возможностей.

Версию его программы можно скачать тут: http://cronsult.com/jndmpcopy_man.aspx

Настраиваем Data Ontap Simulator 8

В предыдущей статье я показал, как поставить виртуальную машину, в виде которой сейчас идет симулятор 8.0.1 на сервер VMware ESX. А сейчас попробуем начать с ним работу.

Как я уже рассказывал в предыдущем посте, Data Ontap Simulator это виртуальная машина, в которой работает версия Data ONTAP 8 для выполнения в среде VM. Data ONTAP 8 базируется на OS FreeBSD, однако, вопреки распространенному (ошибочному) мнению, Data ONTAP 8 это НЕ FreeBSD. Это даже не программа под FreeBSD. Это самостоятельная OS, которая использует FreeBSD как загрузчик своего kernel space code, а также использует некоторые ее ресурсы, например driver model, и драйвера оборудования. Ситуация была примерно та же, что с гипервизором VMware ESX-не-i, если вы помните, там сперва грузился RedHat, под которым затем запускался как модуль собственно ESX, который уже Linux не являлся. Именно этим объясняется то, что мы в прошлой статье создали VM типа “FreeBSD 64-bit”, действительно, сперва VM загружается с использованием loader FreeBSD, а затем использует ее драйверную модель для внешних устройств.

Симулятор, как я уже рассказывал выше, это полноценная версия Data ONTAP, за некоторым исключением: установлено ограничение по поддерживаемой емкости, не работает протокол FC (но работает iSCSI) и, в настоящий момент, реализована только одноконтроллерная конфигурация. Но для экспериментов и обучения этого будет вполне достаточно.

Давайте, для начала, отключим на симуляторе Autosupport. Симулятор это экспериментальная площадка, и лучше будет не беспокоить поддержку NetApp странными сообщениями, которые будет при наших экспериментах посылать”в центр” служба Autosupport. Войдя в консоль даем команду:

options autosupport.enable off

Штатным образом Simulator приходит с набором из 28 “как-бы дисков” размером 1GB (как я уже сказал, для экспериментов этого объема достаточно). Изначально, только 3 диска назначены (assigned) контроллеру, и на них создан root volume на RAID-DP. Остальные диски помечены как unassigned. Назначим оставшиеся диски нашему симулятору:

disk assign all

Теперь добавим ключи-лицензии. Эти ключи предназначены только для симулятора, и не будут работать на физической системе. Можно установить только то, что используется на вашей продакшн-системе, или поставить дополнительные лицензии, чтобы посмотреть “что это и как работает”, или же просто все, и экспериментировать со всеми возможными фичами.

  • a_sis MTVVGAF
  • cifs DZDACHD
  • disk_sanitization PZKEAZL
  • http NAZOMKC
  • flex_clone ANLEAZL
  • iscsi BSLRLTG
  • multistore NQBYFJJ
  • nearstore_option ELNRLTG
  • nfs BQOEAZL
  • smdomino RKBAFSN
  • smsql HNGEAZL
  • snapmanagerexchange BCJEAZL
  • snapmirror DFVXFJJ
  • snapmirror_sync XJQIVFK
  • snaprestore DNDCBQH
  • snapvalidator JQAACHD
  • sv_linux_pri ZYICXLC
  • sv_ontap_pri PVOIVFK
  • sv_ontap_sec PDXMQMI
  • sv_unix_pri RQAYBFE
  • sv_windows_ofm_pri ZOFNMID
  • sv_windows_pri ZOPRKAM
  • syncmirror_local RIQTKCL

Лицензионный ключ – это 7 заглавных букв после имени функции. Для того, чтобы ввести лицензионный ключ дайте команду:

license add XXXXXXX

Допустим, мы решили оставить 3 уже назначенных диска в отдельном root aggregate (так рекомендуется по ряду причин), однако если ваша реальная система мала, то вам, возможно, не захочется терять эти 3 диска и их IOPS-ы, тогда возможен вариант с единым общим aggregate, не выделенным под root volume, а общим с пользовательстими данными. Тогда вам нужно будет создать из имеющихся дисков новый aggregate, перенести root volume на него, затем удалить старый том и aggregate, и освободившиеся 3 диска добавить к созданному вами “большому” aggregate. Как это сделать я уже писал в блоге ранее.

Если же мы собираемся оставить 3 диска root vol в отдельном aggregate, то просто создавайте новый aggregate на оставшихся 25 дисках. Однако тут имеет смысле сделать небольшие изменения в опциях системы. Дело в том, что размер RAID-группы по умолчанию в Data ONTAP равен 16 дискам (а максимальный для дисков FC, SAS и виртуальных дисков симулятора – 28). Если вы создаете большой единый aggregate на всех 25 дисках, то, при установленном размере RAID-группы равной 16, он создастся так:

Сперва будет взято 16 дисков, из которых 2 будут RAID-DP parity и dparity, а остальные 14 будут data в RAID-группе rg0. Затем на оставшихся будет создана вторая RAID-группа (rg1), из оставшихся 9 дисков, которые, в свою очередь, станут двумя parity и 7 data. В дальнейшем, если в aggregate добавляются новые диски они добавляются в “неполную” RAID-группу, пока она не достигнет заданного в опциях размера в 16 дисков, а следующие создадут еще одну новую “неполную” группу.

Логично было бы, особенно на небольшом числе дисков, не полагаться на такую автоматику, а самостоятельно расчитать и создать RAID-группы, по возможности равного размера. То есть, с точки зрения порядка, аккуратности (да и производительности) вариант 12+12+1 hot spare будет лучше, чем 16+8+1hs. А в нашем случае мы поступим еще лучше, мы просто увеличим заданный размер RAID-группы до максимума (28), или, хотя бы до 25. Тогда все наши диски поместятся в одну группу. Дадим в консоли команду:

aggr options aggr1 raidsize 28

Теперь добавим оставшиеся unassigned диски в созданный aggr0

aggr add aggr1 24

Мы оставим один диск под spare, это требование Data ONTAP. Для того, чтобы в логах не валились сообщения о нехватке spares, проверьте значение опции:

options raid.min_spare_count 1

Здесь 1 – количество spare для данного контроллера. Одного будет вполне достаточно, а при количестве дисков более 16 поставить 0 система не даст.

Имеет смысл также уменьшить резерв под snapshots уровня aggregate. Что это я уже тоже писал в блоге, есл вкратце и в двух словах – это вам не надо, это для Metrocluster, синхронной репликации, и может помочь для ремонта сильно поврежденной WAFL. Если у вас этого всег нет, то можете этот резерв убрать и выключить расписание создания их.

snap reserve -A aggr1 0
snap sched -A aggr1 0

Отдельно отмечу, это ТОЛЬКО для специальных, внутренних снэпшотов уровня aggregate, на обычные и привычные пользовательские снэпшоты уровня volume и файлов это не влияет, они буду работать по-прежнему, и вы по-прежнему сможете их использовать.

Вот теперь все готово к созданию томов и экспериментам. Можете начать из консоли, или же подключить к симулятору System Manager, если вам в GUI привычнее. Симулятор, повторюсь, работает и ведет себя идентично реальной системе хранения (за вычетом FC, SnapLock и ограничения по объему хранения). К нему можно подключить любой софтовый продукт (System/Operations/Protection/Provision Manager, SnapManager, VSC), настроить на него репликацию, использовать его как получатель (secondary) или источник (primary) для SnapVault, и так далее.

В основу этого поста легла статья http://mtellin.com/2011/01/03/getting-started-with-the-netapp-ontap-8-0-1-simulator/.

В следующей статье я покажу, как можно добавить диски симулятору, сверх предустановленных 28, а также добавить serial console или изменить предустановленный серийный номер и SystemID, если вы планируете использовать несколько разных симуляторов в одной сети.

NetApp - 20 лет.

Вот что пишет у себя в блоге Дейв Хитц, сооснователь и вице-президент компании:

NetApp была задумана двадцать лет назад, 2 декабря 1991 года, в ресторане Hobee’s Restaurant в Mountain View.
Первым придумал идею storage appliance - “устройства хранения данных” Майк Малколм (Mike Malcolm), и он позвонил Джеймсу Лау (James Lau) и мне, обсудить, не хотим ли мы создать с ним такую компанию. Джеймс был занят, так что Майк и я встретились пообедать и обсудить тему без него. Люди всегда говорят про “рисование на салфетках” о такого рода дискуссиях, но, если вы когда-нибудь пробовали использовать шариковую ручку на рыхлой салфеточной бумаге, то согласились бы, что салфетки можно бы было сделать для этого и поудобнее. И вот мы принялись писать. Это был очень долгий обед. После него мы с Майком потратили еще час, разговаривая на парковке перед рестораном. Я был глубоко впечатлен идеей, и немедленно позвонил Джеймсу, и сказал, что он должен встретиться с Майком завтра или послезавтра.

Полагаю, что NetApp была создана в апреле 1992, когда мы оформили проект как компанию и получили первое финансирование – по пятьдесят тысяч от первых трех бизнес-ангелов – но я всегда считал, что компания как концепция родилась именно 2 декабря..

Right-sized Usable Capacity для разных дисков

Я уже упоминал, что начиная с DataONTAP 7.3.1 емкость aggregate в системах NetApp FAS рассчитывается исходя из “правильной” usable емкости дисков, “после налогов и вычетов” и без учета дисков parity.

Вот каковы right-sized емкости используемых в системах NetApp дисков, исчисленных в “двоичных” единицах (по основанию 1024):

Marketed Capacity Right-sized Usable Capacity
100 GB (SSD) 84.574 MiB
300 GB (FC/SAS) 272.000 MiB
450 GB (FC/SAS) 418.000 MiB
500 GB (SATA) 423.111 MiB
600 GB (FC/SAS) 560.000 MiB
1 TB (SATA) 847.555 MiB
2 GB (SATA) 1.695.466 MiB

 

При дальнейших расчетах также не забывайте про “основание 1024”, то есть, что
1695466 MiB = 1655,7 GiB = 1,62 TiB

При расчетах в “двоично-десятичной” арифметике для перехода от “мегабайтов” к “гигабайтам” недостаточно “сдвинуть запятую в числе на три позиции влево”, помните об этом . Разница между “терабайтом” и “тебибайтом” составляет почти 10%!

NetApp - №1 в Германии!

Я уже упоминал факт того, что в Германии у NetApp традиционно очень сильные позиции, более того, там он обгоняет даже EMC.

Вот какую интересую картинку я нашел на днях, с источником в виде IDC Storage Tracker March 2011:

IDC Storage Tracker Germany 2011

UPD: А если шпрехаете по дойчу, то можете попробовать почитать вот это:
http://www.computerwoche.de/hardware/data-center-server/2500678/
Там еще очень интересные картинки динамики того, как перераспределяются юзеры между вендорами от года к году (кто от кого уходит и к кому переходит).

Как поставить Data ONTAP Simulator v8 на VMware

Я уже рассказывал в этом блоге про то, что такое Data ONTAP Simulator, и чем он полезен, не только когда у вас нет “живой” системы хранения NetApp под руками, но даже, причем в большей степени, когда она у вас есть. На таком симуляторе можно упражняться “на кошечках”, можно проверять какие-то свои идеи, ставить эксперименты, отлаживать какие-то решения (не на продакшновом же сторадже это проделывать?), наконец учиться и обучать новичков.

Однако, как вы знаете, Data ONTAP 8 отличается от DOT7 довольно прилично. Была изменена платформа, на которой выполняется код собственно NetApp. В результате теперь по другому выглядит и Симулятор. Если раньше, для версии 7, это была программа под Linux, то Симулятор под Data ONTAP v8 это самостоятельный образ виртуальной машины, который можно запустить из под, например, VMware Player, или установить ее как VM в ESX.

Вот как раз этому варианту и посвящена эта статья, которую в оригинале я подсмотрел на http://mtellin.com/2010/03/12/use-ontap-8-0-7-mode-simulator-on-esx/

Continue reading ‘Как поставить Data ONTAP Simulator v8 на VMware’ »

Время RAID recovery для разных дисков

Полезное из документации. В таблице ниже приведены оценочные затраты времени на так называемый zeroing (процедуру физического стирания содержимого диска), на процедуру Rapid RAID Recovery (применяемую, когда диск, помеченный неисправным, читается и часть данных с него может быть извлечена непосредственно) и обычного, классического RAID Reconstruction (при котором данные с вышедшего из строя диска пересчитываются из parity).

Disk capacity Type RPM Zeroing (hrs) Rapid RAID recovery (hrs) RAID Reconstruction (hrs)
300GB SAS 15KRPM 1,5 1,0 2,0
450GB SAS 15KRPM 2,2 1,5 2,3
600GB SAS 15KRPM 2,5 1,8 2,8
450GB SAS 10KRPM 2,3 2,5 3,8
600GB SAS 10KRPM 2,6 3,8 4,4
500GB SATA 7.2KRPM 2,5 2,8 5,2
1TB SATA 7.2KRPM 4,3 5,5 9,3
2TB SATA 7.2KRPM 5,6 12,8 18,5

Hybrid Aggregate

Некоторые новости с прошедшего в Риме NetApp Insight 2011, главного мирового мероприятия NetApp, на котором, обычно, представляются все новинки года. На этот раз я обратил внимание на объявленную любопытную технологию, которая появится в Data ONTAP 8.1.1, под названием Hybrid Aggregate.
Вот что это такое.

Как вы знаете, NetApp использует flash, прежде всего, в форме “расширения кэш-памяти”, а не как “эмуляцию диска” – SSD – Solid State Disk, у такого решения множество преимуществ на практике, и широкий успех Flash Cache, устройства для систем хранения NetApp, представляющего собой плату с 256/512/1024GB flash на ней, и устанавливаемую внутрь контроллера FAS3200/6200, тому подтверждение.

Однако у NetApp есть и “классические” SSD, а теперь появилась и новая интересная разработка в области работы с “традиционными” SSD. Ведь не секрет, что не существует волшебной “серебряной пули”, разом решающей абсолютно все проблемы пользователя, что бы там по этому поводу ни утверждали в отделе маркетинга. Вот для областей, где Flash Cache работает недостаточно эффективно, и предназначены новые разработки.

Hybrid Aggregate это, как нетрудно догадаться из названия, “составной” aggregate, состоящий из обычных “врашающихся” дисков и SSD. В такой структуре диски SSD обеспечивают “кэш на запись” для традиционных, “вращающихся” дисков в составе этого aggregate.

Основные отличия Hybrid Aggregate от Flash Cache следующие:

  • Работает в том числе и на запись. В тех случаях, когда характер нагрузки системы пользователя представляет собой, преимущественно, большое количество операций записи сравнительно небольшими блоками, Flash Cache неэффективен, так как практически не ускоряет записи (в определенной степени он их ускоряет, но только за счето того, что, высвобождая ресурсы дисков за счет кэширования чтения, оставляет больше на обработку операций записи). Следует отметить, что рабочая нагрузка, представляющая собой, главным образом, объемный random write мелкими блоками, это довольно специфическая и не слишком массовая задача.
  • Hybrid Aggregate может быть несколько на одной системе, каждый из них может быть настроен индивидуально и независимо от других. Flash Cache работает на все aggregate разом, хотя и можно политиками FlexCache настроить приоритеты и политики кэширования для разных томов.

Как мне видится, преимущества от Hybrid Aggregate получат прежде всего большие и очень большие системы, с сотнями дисков, с большими aggregates и очень большим трафиком ввода-вывода, или же системы со специфической рабочей нагрузкой (большой объем преимущественно записей мелкими блоками), кроме того следует помнить, что Hybrid Aggregate не исключает использование и Flash Cache, он вполне может использоваться вместе с Hybrid Aggregate на той же системе. Таким образом, появление Hybrid Aggregate не стоит трактовать как “отказ от Flash Cache” (я специально делаю это замечание для “паникеров” ;) или признание его неэффективности, это, скорее дополнение в ранее незакрытом сегменте рабочих нагрузок и специфических решений.

Новые цены на FAS2020

Объявлены новые, последние розничные цены на преконфигуренные бандлы FAS2020.

И хотя 2020 это совсем не “звездолет”, это все же вполне себе NetApp, и для многих применений он может вполне удовлетворительно подойти.

Обратите внимание, что откладывать покупку уже времени нет, это последние FAS2020, “распродажа товарных остатков”, с ноября месяца официально “младшим” в семействе FAS2000 назначен FAS2040, который мощнее, но и дороже. Если вы хотели 2020, то вот время купить его. Это задняя цена и заднее не бывает :)

В бандлы включена фиксированная конфигурация на 1 или 2 контроллера, и 12 дисков разной емкости, а также набор лицензий на функциональность, гарантия на “железо” на 3 года, с доставкой замены в режиме Next Business Day, а также трехлетняя попдписка на обновления ПО (SSP – Software Subscription Program) и сопровождение систем (техподдержка через сайт now.netapp.com / support.netapp.com).

Bundle Цена USD
FAS2020, 12X1TB, base sw, 36M SSP NBD-Part-Shippment 7450
FAS2020, 12X2TB, base sw, 36M SSP NBD-Part-Shippment 10950
FAS2020A, 12X1TB, Windows Bundle sw, 36M SSP NBD-Part-Shippment 12950
FAS2020A, 12X600GB, Complete Bundle sw, 36M SSP NBD-Part-Shippment 13950

 

В состав лицензий входят:

  • все доступные протоколы доступа: CIFS, NFS, iSCSI, FCP
  • Base pack – основной набор функциональности, такой как:
    • Snapshots – до 255 снэпшотов на каждый том, не влияющих на производительность
    • Thin provisioning не зависящий от хост-OS
    • Дедупликация – блочная, с размером блока 4KB
    • SyncMirror – синхронная репликация как внутри, так и между системами по IP
  • Wndows bundle это Base pack плюс :
    • SnapRestore – быстрое восстановление тома целиком из снэпшота
    • SnapVault – D2D backup
    • SnapMirror – асинхронная/синхронная/полусинхронная репликация по IP
    • SnapManager – семейство продуктов для создания консистентной резервной копии в снэпшоте и восстановления из нее для MS SQL Server, MS Exchange, MS Sharepoint, Oracle DB, SAP, VMware ESX и MS Hyper-V.
    • SnapDrive – средство создания и управения снэпшотами на системе хранения с хост-OS (сервера) для Windows и UNIX/Linux.
    • NetApp DSM – Device-specific module для Windows MPIO.
  • Complete bundle это все перечисленное выше, плюс еще несколько лицензий:
    • FlexClone – возможность создавать томы-клоны данных
    • Multistore – создание независимых “виртуальных систем хранения” внутри одной физической
    • SnapLock – средство неизменяемого хранения данных (WORM – Write-once, Read-many)

Перечисленные бандлы по новым ценам доступны к заказу партнерами у дистрибуторов, цены со склада в Москве и включают в себя НДС.

Позволю себе также некоторые пояснения и уточнения тут привести.

Первые две позиции это одноконтроллерная конфигурация. Минус одноконтроллерной конфигурации – отсутствие HA-cluster failover. Но большой плюс – в том, что вы можете все 12 дисков использовать в одном aggregate и в одном RAID. В случае двухконтроллерных конфигураций (две следующие, с А) вам придется имеющееся количество дисков разбить пополам, соответственно меньше будет производительность и доступное пространство. Схема без разбивки очень выгодна с точки зрения получившегося объема хранения и производительности.

Если вы не будете гнаться за эфемерностью “кластерной отказоустойчивости” и “отсутствию единой точки отказа™” а предпочтете одноконтроллерную конфигурацию, то вы можете получить больше места и бОльшую производительность за меньшие деньги. При этом, напомню, все системы NetApp поставляются с трехгодичным гарантийным сервисом по “железу” уровня NBD onsite delivery, и это в самом деле NBD – Next Business Day delivery (не просто “время реакции”). NBD = Next Available Flight для территорий “вне Москвы”, по понятным причинам. Это значит, что в случае выхода из строя контроллера, замена для него будет доствлена на следующий рабочий день.

Помните также, что диск “на один миллиард байт”, с маркетинговым названием “1TB”, в реальной жизни меньше на 9,96% (за счет разницы между двоичной и двоично-десятичной арифметикой), а так как NetApp использует для ряда внутренних функций увеличенный сектор, то диск “1TB” будет иметь “полезный” объем 827,6Gib, а “2TB” – 1655,7GiB, именно исходя из этих величин и надо считать usable space системы хранения.

Давайте, для примера, посчитаем.

12 дисков “1TB”, физической реальной емкостью 828GiB. Один диск на HotSpare, два – на RAID-DP parity. Так как для SATA допустимый размер RAID-группы типа RAID-DP равен 16, то мы можем все оставшиеся диски поместить в одну группу, и распараллелить ввод-вывод по ним всем, минимально потеряв на дисках parity. 12 дисков – 1 Hot Spare – 2 parity = 9 дисков

827,6GiB x 9 = 7452 GiB – 10% WAFL overhead = 6703 GiB usable space для ваших данных, пока без учета дальнейшего возможного выигрыша от deduplication, thin provisioning и snapshots. При этом ввод-вывод вашей задачи будет параллельно осуществляться на все 9 дисков системы хранения.

При этом в случае двухконтроллерной конфигурации вы будете вынуждены из 12 дисков отдать два hotspare (каждому контроллеру свой) и два раза по 2 на RAID parity. В результате вы получите всего три диска под данные на каждом из контроллеров. Очевидно, что это не только уменьшит доступную емкость, но и снизит возможное быстродействие, так как ввод-вывод буде распараллеливаться на втрое меньшее число дисков (3 против 9).

827,6GiB x 3 = 2484GiB – 10% WAFL overhead = 2234,5GiB usable space на каждом из двух контроллеров, то есть:
2234,5GiB х 2 = 4469GiB на обоих, на тех же дисках, при использовании двухконтроллерной конфигурации.

HA-cluster из двух контроллеров это, безусловно, большое подспорье в отношении надежности, но насколько оправданно на столь маленьком количестве дисков платить такую цену за него – вам решать. Я только хотел показать, что одноконтроллерная конфигурация также имеет право на существование и свои значительные плюсы на практике.

Так что выбирайте, но острожно, но выбирайте :) И помните, что это последняя возможность купить FAS2020.

Надеюсь, что вскоре я смогу вам также назвать и цены на аналогичные бандлы 2040 и 2240, как только решение по их конфигурациям и ценам будет принято для России.

Для покупок обращайтесь к вашему местному партнеру NetApp, а он знает как и где заказать наванные бандлы и доставить их вам.

23/0.561