Tag Archive


مفهوم MAID

مفهوم MAID


در اصطلاحات اختصاصی استوریج واژه ای به نام MAID که همان Massive Array of Idle Disks می باشد وجود دارد که تکنولوژی اطلاق می شود که در آن از گروه های بزرگ هارد دیسکها که حتی بعضی مواقع به هزار تا هم می رسد استفاده می شود و فقط با درایوهایی که می توانند بصورت فعال و پویا در زمان مورد نظر کار کنند.

MAID یک راهکار استوریجی می باشد که بار روی هارد و برق مصرفی در آن را کاهش می دهد. بدلیل اینکه فقط هاردهای مشخصی در یک زمان می چرخند و به معنای واقعی کلمه تعداد بسیار زیادی از هاردهای بیکار در سیستم وجود خواهند داشت. از اینرو سیستم گرمای به نسبت کمتری در مقایسه با سیستم استوریج های بزرگ تولید می کند.

یکی از انواع MAID که Copan می نامند با هارد دیسکها به صورت Tape Library VTL رفتار می کند و فقط در صورت نیاز از هاردها استفاده می کند.

یک آرایه Copan می تواند شامل صدها هارد دیسک چند ترابایتی باشد که بین یکدیگر برق مصرفی ، کنترلر و کابینت را به اشتراک گذارند.


پیکربندی RAID در سرورهای HP با محیط Array Configuration Utility 

انواع RAID و کاربرد آنها

تفاوت RAID های نرم افزاری و سخت افزاری


دستورات استوریج های VMAX and Symmetrix SYMCLI

دستورات استوریج های VMAX and Symmetrix SYMCLI


Before you can do anything with a VMAX, you need to install the Solution enabler software, which you can get from powerlink.emc.com. You download the software, unzip or untar it, run the emc-install program and get the product licensed.
Now you have your software, but you need to run an initialisation command before you can connect to your DMX. Navigate to /usr/symcli/bin and run;

 symcfg discover
symcfg list 

The first command gets information from the DMX and uses it to build a configuration database on your host. The second command lists that information out.

However symcfg is a very powerful command that can be used to display and alter the configuration of a VMAX. My preference is to use symconfigure for most of this, but symcfg can be used to manage VMAX locks, RDF and director ports, gatekeeper devices, hosts and host ports, mainframe connections, and more.

Discover all VMAX arrays connected to this host, then build or refresh the Symmetrix configuration database file using this information:

  symcfg discover

Display information held in the Symmetrix configuration database about all attached Symmetrix arrays

  symcfg list

Display more detailed information about the attached Symmetrix arrays and their directors

  symcfg list -v -dir all

Display detailed information about a specific director, in this case 0E

  symcfg list -v -dir 0E

Display information about all front-end directors on Symmetrix array 824

  symcfg list -SA ALL -sid 824

Display information about all the registered hosts that are connected to the Symmetrix array 824

  symcfg list -connections -sid 824

To list all gatekeeper and database access locks, enter:

  symcfg list -semaphores

To verify whether the Symmetrix 824 configuration and the Symmetrix configuration database are in sync, enter:

  symcfg verify -sid 824

list the port flags for port 0 on director 5 position A

  symcfg -sid 38 list -sa 5A -p 0 -v

Take the above port offline (necessary to change port flags – and remember this could make storage unavailable to users so use with caution)

  symcfg -sid 38 offline -sa 5A -p 0 

enable port flag vcm-state on the above port

  symcfg -sid 38 set port 5A:0 vcm-state=enable 

put the port back online

  symcfg -sid 38 online -sa 5A -p 0 


The symconfigure command lets you make changes to your Symmetrix device, for example to add new volumes, add or change port and host assignments and configure remote mirroring RDF devices. It updates the symm.bin file on the symm. device. The command cannot be shortened, symcfg is a different command

As part of making changes, symconfigure lets you save the current configuration, reserve devices to prevent others from using them, and gives you a number of query, list and verify options to check the current status of a symmetrix and validate any proposed changes before applying them.

You run symconfigure from a host server that is connected to the symmetrix, If anything happens to that host or the connection to the symm. while a change was in progress then the symm. could be left in an indeterminate state. To cater for this scenario, symconfigure has an abort option that lets you back out uncompleted changes.

symconfigure itself has a fairly small set of parameters, it does most of its powerful processing by reading a command file. The simplest command is symconfigure -h, the online help facility. The other symconfigue commands require a -sid parameter which identifies the Symmetrix that you are going to change. Before you want to start to make changes you will probably want to see your existing Symmetrix configuration.

If the query command shows that a hung session exists, then no more updates will be possible as any session puts a lock 15 on the symm.

Checking VMAX status using symconfigure and managing reserves

These examples commands are running against a VMAX with a symmetrix ID of 123

Query VMAX 123 to see what total freespace is available

    symconfigure -sid 123 -freespace -unit mb list 

Display the version number of the SYMCLI, SYMAPI and the configuration server. -sid is optional, leave it off and the versions for all attached symms are displayed.

    symconfigure -sid 123 -version -v 

The query command will check for any existing active configuration activity. If this command cannot get the information, it will keep retrying. You can control this with the -i and -c options which are interval between retries and number of retries.
Query a VMAX 8 times at 5 second intervals to see if any updates are running

    symconfigure -sid 123 -i 5 -c 8 -v query

Query a VMAX for reserves

    symconfigure -sid 123 -reserved list

Query a given reserve to get more details

    symconfigure -sid 123 -reserve-id 4567 show

Safely attempt to release reserve 4567

    symconfigure -sid 123 -reserve-id 4567 -noprompt release

Symconfigure examples using the command file

If you are planning updates to your VMAX configuration, then generally the best way to do this is to put all your updates into a command file, then run that file through the symconfigure command. The advantages of doing this is that you can get your commands peer checked by a colleague and syntax checked by the system before you run them. Each command has three options,
‘preview’ which checks the syntax of your command list;
‘prepare’, which also checks your syntax, then checks that the VMAX is in a healthy enough state to process the commands, with enough free resources to process the command,
‘commit’ which does the first two, then applies the updates.

The basic syntax for running symconfigure updates using a command file called command.txt is

    symconfigure -sid 123 -v -file command.txt preview  
symconfigure -sid 123 -v -file command.txt prepare
symconfigure -sid 123 -v -file command.txt commit 

Some optional parameters are -noprompt which suppresses the ‘do you really want to …’ messages and -v for verbose which means echo results back to the terminal

Command file examples

Changing devices

Create 2 small Gatekeeper devices. Gatekeepers are used to communicate with the VMAX. EMC recommends 4 gatekeepers per port and they are typically created with just 6 cylinders.

    create dev count=2 size=6 emulation=fba;

Create 20 bigger Standard devices

    create dev     count=20,
SIZE=50 GB, 

Note that the commands are not case sensitive, parameters can be separated by commas or spaces, can span more than one line, can contain extra white space, but must end with a semicolon ‘;’ .

Add 6 a new spare devices

create spare count=4, format = 520;

Older symmetrix devices has 512 bytes in a block, new devices have 520 bytes in a block.

To delete disks use

		delete dev Device-name

Working with Metas

EMC split a physical device into between 1 and 128 hyper volumes, which are then combined together to form meta devices. A meta corresponds to a LUN as presented to a host, so a LUN can be bigger than a physical device. A meta-device can consist of up to 1024 hypers, but all the hypers must be the same size and type and have the same protection. Valid hyper sizes range from between 0.5 and 32GB. A Meta can be concatenated, that is, it can consist of hypers strung together, or it can be striped, when the data is striped across the hypers. The first device in a meta is known as the meta head.

The starting point is to find any unmapped devices using the command symdev list -noport. If any of these devices are allocated as BCV pairs or defined to device groups, then split them out using commands like this

 symmir -g group_name split
symmir -g group_name rmall

Examples of symconfigure command files working with metas

define a concatenated meta and add 2 more devices to it. Concatenated metas are best for sequential data access, and they are easier to gorw or shrink that striped metas.

   form meta from device 028
add dev 015:016 to meta 028;

define a striped meta and add 2 more devices to it. Striped metas are best for random data access, but they can’t be shrunk and are more difficult to grow.

   form meta from device 02b
add dev 017:018 to meta 02b;

Split meta 02b back into it’s constituent hypers – this will destroy any data on the meta!

	dissolve meta dev 02b;

remove device 016 from meta 028

	remove dev 016 from meta 028;

Using SYMTIER to work with FAST tiering

Two types of FAST tier exist, disk provisioned virtual tiers and virtual provisioned storage tiers. ‘Disk provisioned’ is also split into static and dynamic. The following command will list all the storage tiers in array ‘123’, including DiskGroup and Virtual Pool Tiers. If you just wanted to list DiskGroups or Virtual Pools you would add the switch -dp or -vp as appropriate.

symtier -sid 123 list

To get more detailed information about a specific tier use this command – obviously with your subsystem id and tier name.

symtier -sid 124 show -tier_name TEFD1


To work with FAST tiers, you need to be able to create and delete them, and also add and remove disks from them. The following command will create a static, disk provisioned pool called ‘TSDP1’, configured in RAID5, 3+1 format in disk array ‘123’ from SATA disks. Alternative disk tecnology options are FC (Fiber Channel) or EFD (Enterprise Flash Drive). -dsk_grp is the disk groups to be added to the tier. In this case we are allocating a single disk group ID=2, but you can allocate a list of disk groups, and you can allocate them by name.

symtier -sid 123 create -name TSDP1 -inc_type static -tgt_raid5 -tgt_prot 3+1
-technology SATA -dsk_grp 2

This command will create a flash disk tier in RAID1 format. -vp means this tier will be allocated using virtual provisioning

symtier -sid 123 create -name TEFD1 -tgt_raid1 -technology EFD -vp

To add a disk group to an exisiting tier use the following command. This adds ‘disk group 3’ to existing Storage Tier ‘TSDP1’.

symtier -sid 123 -tier_name TSDP1 add -dsk_grp 3

and to remove it again use

symtier -sid 123 -tier_name TSDP1 remove -dsk_grp 3

You can also rename a tier if you did not like the existing naming standard, so ‘TSDP1’ becomes ‘Tier_qxy29p


symtier -sid 123 rename -tier_name TSDP1 -name Tier_qxy29p1

and finally, to delete a tier use this command.

symtier -sid 123 delete -tier_name Tier_qxy29p1

Examples of symconfigure command files for mainframe disks

Create a mainframe striped meta. This must include at least 4 meta devices. This example creates 4 * 500 cylinder metas, then uses them to create a 2000 cylinder striped CKD meta in a RAID1 configuration.

   create dev count=4 size=2000
emulation=CKD-3390 config=2-way-mir

PAV aliases are used to allow multiple concurrent access to mainframe devices. See the PAV section for details. The following commands can be used to allocate PAV aliases. The first command will add 4 aliases to a specific symm. device. The second command allocates a range of aliases to a sub system

  add pav alias to dev 02b alias count=4 
add pav alias range 127:255 to mvs ssid=B000 

Some other useful commands


One of the main uses of the symdev command is to see what free hypers are available. The command to do this is

   symdev list -noport
symdev list -da all space   
symdev list -meta 
symdev show meta head address 

The second command will show all backend space available
The third command will list out all the meta heads, and also tell you how many hypers are associated with each meta head.
The last command will list out all the details for one meta. The show command usually gives more detail than list, as it reads its information from the host database.


Returns a string with a detailed description of any return code generated by any SYMAPI function
To return a string for error number 10, enter:

   symapierr 10

The following will be output:

SYMAPI Error Message: No Symmetrix devices found with microcode version 5x63 or up.


This command checks which devices are mapped to a host
To work out directory and port mappings enter:

   syminq -pdevfile

back to top


متدهای ذخیره سازی اطلاعات

امروزه یکی از مهمترین فاکتور ها در طراحی شبکه های سازمانی متد ذخیره سازی اطلاعات است. افزایش حجم اطلاعات، بازیابی اطلاعات و امنیت اطلاعات ذخیره شده از بزرگترین چالش های رو به رو است. در این مطلب سه تکنولوژی مختلف مورد بررسی قرار می گیرند.

توجه: این مطلب مفاهیم ابتدایی و مقدماتی را به صورت تئوری مورد بررسی قرار می دهد.

DAS – Direct-Access Storage


به سیستمی گفته می شود که در آن Storage ها مستقیما به Server یا WorkStation متصل باشند. با توجه به آن تعریف یک Hard Disk عادی که با استفاده از یکی از اینترفیس های رایج  SATA، IDE ، SCSI و یا SAS به سیستم متصل شده یک نوع DAS تلقی می شود. اما به عبارت رایج DAS به دسته از Hard Disk های داخلی و یا خارجی گفته می شود که به یک Server متصل باشد. ویژگی اصلی DAS آن است که آن Storage تنها در اختیار یک سیستم قرار می گیرد. DAS یک راهکار با توجیه مالی مناسب برای سرور هایی است که به سرعت دسترسی به اطلاعات بالا احتیاج داشته باشند اما حجم اطلاعات مورد ذخیره سازی آن ها اندک باشد. به عنوان مثال می توان به DHCP,DNS, Wins و DC ها اشاره کرد. با استفاده از DAS دسترسی به اطلاعات به صورت Block Base خواهد بود به آن معنا که دیتا در بلاک هایی بدون فرمت منتقل می شود. این تکنولوژی بر خلاف File Base عمل می کند. اغلب DAS برای تمیز دادن تکنولوژی های ذخیره سازی شبکه ای NAS و SAN با سایر تکنولوژی هایی ذخیره سازی غیر شبکه ای به کار می رود. معمولا اتصال DAS تنها به یک Server ممکن است البته با استفاده از برخی کنترلر های خارجی و در برخی از انواع DAS های خارجی امکان اتصال دو یا بیشتر سرور هم موجود است. رابط بین سرور و DAS معمولا HBA یا کنترلر SCSI است. علاوه بر پروتکل های ارتباطی که در فوق ذکر شد، با استفاده از Fiber Channel یا FC نیز امکان ارتباط  DAS با Server وجود دارد. با به کار گیری روش های رایج خنک سازی دوبل، مکانیزم ذخیره سازی RAID می توان Fault Tolerance را بهبود بخشید.

HBA یا host bus Adaptor یک یک سخت افزار است که یک کامپیوتر را به یک شبکه یا تجهیزات ذخیره سازی اطلاعات متصل می کند. این واژه هرچند بیشتر برای تجهیزات eSATA, SCSI و FC استفاده می شود، اما تجهیزاتی که با استفاده از IDE، Ethernet و یا FireWire و USB این امکان را ایجاد می کنند می توانند HBA گفته شوند. در تصویر زیر یک HBA مخصوص SCSI که اینترفیس ISA متصل می شود را می بینید.



نقص به کارگیری DAS در تمام سناریوهای ذخیره سازی ایجاد Islands Of Information یا جزایری اطلاعات است. همانطور که گفته شد، Storage در این حالت اغلب تنها توسط یک سرور قابل دسترسی است بنابراین مدیریت، افزایش هزینه نگه داری و استفاده بهینه از فضای ذخیره سازی با چالش های عمیقی رو به رو خواهد بود. مسئله دیگر آن است به دلیل آنکه DAS مستقیما به یک Server متصل است، در صورت Down شدن Server دسترسی به اطلاعات روی DAS تا راه اندازی مجدد سرور و یا انتقال DAS به یک سرور دیگر ممکن نخواهد بود که این باعث می شود برای Fault Tolerance از Failover Clustering استفاده شود. از روی دیگر هزینه اولیه DAS نسبت به سایر متد ها بسیار کمتر است که این سبب شده تا بیشتر سازمان ها به این روش برای ذخیره سازی اطلاعات روی آورند. در اینجا لازم است توجه شد که هر کدام از متد ها دارای مزایا و معایبی هستند که در سناریو های مختلف طراحی مناسب متفاوت خواهد بود و معایب ذکر شده در خصوص DAS به معنای ناکارآمدی آن نمی باشد. برای مدیریت DAS در ویندوز کنسول Disk Managment و Diskpart.exe به عنوان ابزاری در Command Line استفاده می شود.

NAS – Network Attached Storage


یک دستگاه NAS در واقع یک Server است که دارای یک سیستم عامل خاص مخصوص File Services است. مشهورترین سیستم عامل NAS سیستم عامل FreeNAS است که بر پایه FreeBSD و Open Sourece است. این سیستم عامل دارای قابلیت Web Managment است. FreeNAS به فضایی کمتر از 64MB نیاز دارد. برای آشنایی با این سیستم عامل می توانید از Disk Image مخصوص VMWare آن استفاده کنید. سیستم عامل های مشابه دیگری همچون NASLite و Nexenta نیز با قابلیت های مختلفی در دسترس اند. NAS ابتدا توسط سیستم عامل Novel و با استفاده از پروتکل NCP در سال 1983 معرفی شد. در سال 1984 شرکت SUN آن را در محیط یونیکس و با پروتکل NFS معرفی کرد. سپس Microsoft و 3com با توسعه نرم افزار LAN Manager و گسترش این پروتکل آن را توسعه دادند. 3Server و نرم افزار 3+share اولین سرور خاص برای این منظور بود که از سخت افزار، نرم افزار و چند هارد دیسک اختصاصی بهره می برد. IBM و SUN با الهام گرفتن از از فایل سرور NOVEL سرور های خاصی را ساختند. شرکت Auspex یکی از اولین سازندگان NAS است که در سال 1990 گروهی از متخصصان آن از آن شرکت جدا شدند و سیستمی را ایجاد کردند که هم از CIFT و هم از NFS به صورت همزمان استفاده می کرد. این اقدام در حقیقیت شروعی برای NAS سرور های خاص بود.

ویژگی اصلی NAS پیاده سازی آسان و قابلیت نگه داری حجم قابل توجهی اطلاعات که از طریق LAN قابل دسترسی باشد است. به صورت عملی برخلاف Local BUS دسترسی به اطلاعات از طریق LAN با سرعت کمتری اتفاق می افتد و به صورت File Based است. NAS برای File Server و Web Server ها می تواند یک Storage مناسب باشد. همچنین در محیط های کوچک به عنوان یک Backup Solution بسیار می تواند کارا عمل کند. معمولا NAS Server ها قابلیت اتصال ابزار های ورودی همانند Keyboard و ابزار های خروجی همانند مانیتور را ندارند و برای مدیریت آن ها از ابزار هایی که برای آن منظور طراحی شده استفاده می شود. ابزار مدیریتی NAS ها با توجه به نوعشان متفاوت هستند اما اغلب از طریق نرم افزار Web-Based خودشان صورت می گیرد. تصویر زیر مربوط به FreeNAS است. از آنجایی که NAS Server ها معمولا قابلیت ارتقا ندارند، ممکن است در اثر over load مشکلاتی ایجاد شود که نیاز به بازنگری در متد ذخیره سازی وجود دارد. NAS ها برای نگه داری فایل های Media با حجم زیاد در محیط های کوچک بهترین گزینه هستند. یک دستگاه NAS مناسب باید دارای تکنولوژی های Redundant Power Supply، Redundant data access path و Redundant  Controller باشد و قابلیت استفاده RAID و Clustering را داشته باشد.


پروتکل های مشهور مورد استفاده در تکنولوژی  NAS عبارت اند از:

CIFT – Common Internet File System و SMB – Server Message Block: یک پروتکل لایه Application است که برای دسترسی به فایل ها، پرینتر ها و پورت های سریال به اشتراک گذاشته شده به کار می رود. ابتدا توسط IBM پروتکل طراحی و پیاده سازی شده و سپس توسط Microsoft توسعه داده شده و قابلیت های آن اضافه شده.

NFS – Network File System: در 1984 توسط Sun Microsystems طراحی و پیاده سازی شد. امروزه NFS در اکثر سیستم عامل ها به کار گرفته شده است.

همچنین پروتکل های دیگری همچون AFP – Apple Filing Protocol، FTP، Rsync و… استفاده می شود.

Filer نوعی NAS است که صرفا نقش یک فایل سرور را ایفا می کند. با استفاده از Filer دیگر نیازی نیست تا سرور های گران قیمت شبکه درگیر کار ساده ی فایل سرور باشند. NAS Server ها در درون خود معمولا از SCSI استفاده می کنند.


NAS یك وسیله شبكه محور است و عموما به دلیل یکپارچه سازی محل ذخیره سازی داده های كاربران در شبكه LAN مورد استفاده قرار می گیرد. NAS یك راهکار مناسب ذخیره سازی است كه دسترسی سریع و مستقیم كاربران به سیستم فایلی را فراهم می سازد. استفاده از NAS مشكل تاخیر هایی را بر طرف می سازد كه غالبا كاربران برای دسترسی به فایل های موجود در سرورهای همه منظوره با آن مواجه هستند. NAS ضمن تامین امنیت لازم، تمام خدمات فایلی و ذخیره سازی را از طریق پروتكل های استاندارد شبكه ای فراهم می سازد: TCP/IP برای انتقال داده ها، Ethernet و Giga Ethernet برای دسترسی میانی، و CIFS، HTTP، و NFS برای دسترسی به فایل از راه دور. علاوه بر این، با NAS می توان به طور همزمان به كاربران یونیكس و ویندوز سرویس داد و اطلاعات را بین معماری های متفاوت به اشتراك گذاشت. از نظر كاربران شبكه، NAS وسیله ای است كه دسترسی به فایل را بدون مزاحمت . ایجاد اختلال برای آنها مهیا می سازد. به كمك گیگا بایت اترنت به كارایی بالا و تاخیر كوتاه دست یافته و هزاران كاربران را از طریق فقط یك اینترفیس سرویس می دهد. بسیاری از سیستم های NAS دارای چند اینترفیس هستند و می توانند همزمان به چند شبكه متصل شوند.

SAN – Storage Area networks


SAN در واقع یک شبکه با عملکرد بسیار بالا است که مختص انتقال اطلاعات میان سرور ها و زیرسیستم ذخیره سازی اطلاعات است. از دیدگاه سیستم عامل سرور، محل ذخیره سازی به صورت local است. مهمترین وجه تمایز SAN با DAS آن است که در DAS فضا فقط در اختیار یک سرور است. اما با استفاده از Clustering و SAN می توان هم به بهینه ترین حالت ممکن از فضای ذخیره سازی موجود استفاده کرد و هم مقاومت در برابر خطا در وضعیت قابل قبولی قرار گیرد. با آنکه سرعت انتقال در DAS در گذشته بیشتر بوده، اما امروزه دیگر مسئله سرعت مطرح نمی باشد. راه اندازی SAN پیچیده تر و هزینه اولیه آن بسیار بیشتر از سایر تکنولوژی ها است. SAN زمانی بهترین انتخاب است که حجم عظیمی اطلاعات نیاز به مدیریت دارند و سرعت دسترسی به آن ها پر اهمیت است. SAN برای Backup Server ها گزینه مناسبی است و برای DataBase Server، Streaming Media Server، Mail Server ها در سازمانی بزرگ تنها راهکار موثر است. از سال 2000 پیچیدگی و هزینه بالای SAN کاسته شد و این سبب شده تا شرکت های کوچک تر هم به استفاده ازSAN ها روی آورند. SAN برای ارتباط میان Storage و Server از تجهیزات مخصوصی بهره می برد که به آن SAN Fabric گفته می شود. فضای موجود در SAN تحت پارتیشن های مجازی به نام LUN یا Logical Unit Number تقسیم بندی می شود و به عنوان پارتیشن Local در اختیار Server قرار می گیرد. سیستم عامل ها، File System مخصوص خود را روی LUN ها برقرار می کنند. برای آنکه چند Server بتوانند به دیتا ی ذخیره شده روی SAN دسترسی داشته باشند لازم است از SAN File System یا Clustered file system استفاده شود. SAN File System نوعی File System است که در آن امکان mount بودن هم زمان با چند سرور ایجاد می شود. مثال مناسب برای این نوع فایل سیستم، Cluster Shared Volume یا CSV  است که در ویندوز سرور 2008 R2 جزء ویژگی های Failover Clustering است و برای استفاده در Hyper-V کاربر دارد. برای مدیریت SAN، سیستم عامل ها ابزار های متمایزی ارائه می دهند. به عنوان مثال یکی از این ابزار ها SMfs در ویندوز سرور 2008 است که با استفاده از Add Features می توان آن را به قابلیت های پیش فرض نصب شده اضافه کرد. این ابزار برای ساخت و تخصیص دادن LUN ها کاربرد دارد. ویندوز سرور 2008 ابزار های متعدد دیگری را نیز دارا می باشد.


Fiber Channel یک عملکرد بالا با انتقال بلاکی (Block Based) برای زیرساخت ذخیره سازی اطلاعات را ایحاد می کند. راه انداریFC هزینه بالایی دارد و راه اندازی آن پیچیده است. اجزاء یک شبکه FC شامل سوییچ، Server HBAs و کابل ها است که تمام این اجزا مخصوص است و توسط کمپانی های محدودی ساخته می شود. FC تکنولوژی است که همچنان مشابه قبل مطلوب است. مزیت دیگر فاصله بسیار زیادی است که در این تکنولوژی پشتیبانی می شود.


Fiber Channel over Ethernet یک نوع کپسوله کردن بلاک های FC برای انتقال روی Ethernet است. با این روش با استفاده از 10Gig Ethernet می توان با نگه داشتن زیرساخت FC گستره ی آن را افزود. FCoE در لایه IP قابل Route نیست و محدودیت های خاصی دارد.


internet SCSI یک استاندارد برای توسعه انتقال بلاک های SCSI روی بستر Ethernet با استفاده از TCP/IP است. سرور ها با استفاده از نرم افزار هایی به نام iSCSI Initiator با تجهیزات مربوطه متصل می شوند. راه اندازی iSCSI به صورت عمومی ارزان تر و ساده تر از FC SANs است، اما با صرف نظر از این مزیت، کمپانی هایی که در گستره ی جغرافیایی وسعی به فعالیت می پردازند و به صورت توزیع شده فعالیت می کنند، ممکن است از جزایری از FC SANs بهره ببرند که محدود به 10KM می شود.( با آنکه امروزه برای افزایش 10KM تکنولوژی هایی موجود است، اما پیاده سازی آن ها توجیه اقصادی پیدا نکرده است) با استفاده iSCSI می توان ارتباط را در یک شبکه MAN یا WAN ایجاد کرد. بر خلاف FC Channel، پیاده سازی مایکروسافت از پروتکل iSCSI از پروتکل CHAP و IPSec بهره می برند.  بزرگترین ایراد iSCSI آن است که برای کارایی مناسب لازم است از سوییچ ها و کابل های 10GB Ethernet لازم است استفاده شود که گران قیمت هستند. از جهت دیگر، سرعت انتقال iSCSI از FC کمتر است. شاید بتوان امیدوار بود با پیشرفت و ارزان تر شدن جایگاه مناسب تری برای iSCSI ایجاد شود.


جمع بندی

بدون شک برای شبکه های کوچک استفاده از DAS به عنوان ساده ترین و کم هزینه ترین روش بهترین انتخاب است. همچنین در محیط های کوچک با استفاده از DAS هزینه نگه داری ممکن است کمتر از NAS باشد و به دلیل هزینه بالای راه اندازی و معمولا عدم نیاز، راهکار SAN در شبکه های کوچک استفاده نمی شوند مگر در شرایط خاص. در شبکه های بزرگتر با سایز متوسط، استفاده ترکیبی از NAS و DAS می تواند انتخاب مناسبی باشد. اما با افزایش فضای مورد نیاز هزینه SAN به ازای هر GigaByte فضا کاهش می یابد. با توجه به اهمیت اطلاعات و هزینه نگه داری راهکار SAN باید راهکاری مناسب باشد.


در بررسی هزینه پیاده سازی باید مسئله استفاده بهینه از فضای موجود مد نظر قرار گیرد، هرچند که در محیط های کوچک مورد توجه قرار گرفته نمی شود اما با توجه به نمودار زیر که نرخ استفاده عملی را نمایش می دهد، نمودار دوم باز تعریف می شود که هزینه پیاده سازی و نگه داری SAN نسبت به DAS در آن کاهش چشم گیر پیدا می کند. برای اطلاعات بیشتر اینجا را بخوانید.




فروش استوریج HP

فروش استوریج HP

گروه فنی و مهندسی وی سنتر آمادگی خود را برای ارائه مشاوره فنی و فروش استوریج های HP اعلام می دارد.

شما همچنین می توانید استوریج خود را بصورت آنلاین پیکربندی و قیمت گیری نمایید.

شماره تماس: 88884268

پیکربندی آنلاین

استوریج های HP در دسته های زیر تقسیم بندی می شوند:

HP MSA 1040

HP MSA 2040

HP MSA P2000 G3

HP 3PAR StoreServ

HP D2600

HP D2700

HP D3700


برای دسترسی به آموزشهای دیتاسنتر به شبکه آموزشی وی سنتر بپیوندید.

شبکه آموزشی


فروش استوریج EMC

فروش استوریج EMC

گروه فنی و مهندسی وی سنتر آمادگی خود را جهت تامین انواع استوریج ها و تجهیزات EMC اعلام می کند.

برای قیمت گیری می توانید لیست خرید خود را به ایمیل Sales@vcenter.ir ارسال فرمایید.

شماره تماس: 88884268


معرفی EMC VNX MirrorView

معرفی EMC VNX MirrorView

EMC VNX – MirrorView


نرم افزار EMC VNX MirrorView ارائه دهنده راهکاری برای Replication در لایه بلاک در محصولات EMC VNX محسوب می شود.

این نرم افزار دارای دو Mode برای Remote Mirroring می باشد:

  • MirroView/S Synchronous
  • MirrorView/A Asynchronous

نرم افزار MirrorView به تکنولوژی گفته می شود که در آن اصل دیتای بلاک استوریج که در حالت اکتیو و استفاده می باشند در استوریج سایت ریموت ذخیره می شوند. این سایت ریموت که به آن سایت پشتیبان نیز گفته می شود در حال حاضر یکی از راهکارهای مناسب برای Disaster Recovery محسوب می شود. راهکار MirrorView بر پایه LUN کار می کند به این مفهوم که در عمل Replication یک LUN از سایت اصلی بر روی یک LUN در سایت دوردست یا همان سایت Diaster Recovery ذخیره می شود.



در حالت MirrorView/S که synchronous replication نیز نامیده می شود در فاصله های نزدیک قابلیت Replication همزمان را ارائه می نماید. ار آنجا که در راهکار Synchronous Replication همه چیز همزمان انحام می پذیرد اندازه RPO Recovery Point Objective صفر می باشد.

گردش دیتا در MirrorView/S به شرح ذیل می باشد:

1- هاست به استوریج اصلی VNX وصل شده و یک عمل Write را آغاز می کند.

2- استوریج اصلی VNX داده ها را در استوریج ثانویه Replicate می نماید.

3- استوریج ثانویه VNX خبر اتمام عملیات Write را به استوریج اصلی VNX می دهد.

4- استوریج ثانویه VNX خبر اتمام عملیات Write را به هاست می دهد.

خیلی مهم است که ما از نحوه گردش دیتا در MirrorView/S آگاه شویم. به عنوان شما باید بدانید زمان رفت و برگشت RTT Round Trip Time بین دو استوریج VNX نباید بیشتر از 10 میلی ثانیه باشد. اگر زمان RTT بالاتر از این مقدار باشد مدت زمان پاسخگویی هاست نیز بالاتر خواهد رفت بدلیل اینکه مدت زمان بیشتری برای ارسال Acknowledge برای درخواست Write طول خواهد کشید.



در حالت MirrorView/A قابلیت Replication برای فاصله های بلند را فراهم می سازد. این حالت می تواند برای انجام Replication بین دو دستگاه استوریج VNX مورد استفاده قرار گیرد. در این حالت مدت زمان RTT بسیار بالا می باشد ولی باید به این نکته توجه داشت که این زمان نباید بیشتر از 200 میلی ثانیه باشد. در حالت MirrorView Asynchronous  این نرم افزار ، مدلی برای آپدیت زمان دار تغییرات Track ها در سایت اصلی وجود دارد که با استفاده از این مدل تغییرات در سایت ثانویه با استفاده از فاصله زمانی RPO مورد نظر کاربر انجام می پذیرد.

با استفاده از MirrorView/A Replication اعلام اتمام عملیات نوشتن در زمان دریافت توسط استوریج اصلی به هاست ارسال می شود که اساسا هیچ تاثیر منفی در محیط عملیاتی ندارد در حالی که با استفاده از MirrorView/S همه عملیات نوشتن باید توسط دو استوریج Acknowledge شوند.

گردش دیتا در MirrorView/A به شرح ذیل می باشد:

1- هاست به استوریج اصلی VNX وصل شده و یک عمل Write را آغاز می کند.

2- استوریج اصلی VNX ارسال کرده و هاست را Acknowledge می کند.

3- استوریج اصلی VNX تغییرات را دنبال کرده و بر روی استوریج ثانویه با دستورالعمل RPO مشخص شده توسط کاربر Replicate می نماید.

4- استوریج ثانویه داده ها را دریافت و Ack را به استوریج اصلی ارسال می کند.


نکته مهم: در هر دو حالت MirrorView/A و MirrorView/S گروه های Consistent پشتیبانی می شوند. گروه های Consistent زمانی مورد استفاده قرار می گیرند که ما بخواهیم اطلاعات را با یک ترتیب مشخص بر روی چند LUN مشخص بنویسیم. به عنوان مثال شما اگر در ساختار VMWare خود یک Datastore متشکل از 6 عدد LUN داشته باشید نیاز خواهید داشت برای هر کدام از آنها در وضعیت Consistent بوده و در ارتباط با یکدیگر باشند تا کارکرد بهتری داشته باشند.





دستورات اصلی EMC Navisphere در Naviseccli

Navisphere CLI is a command line interface tool for EMC storage system management.

You can use it for storage provisioning and manage array configurations from any one of the managed storage system on the LAN.

It can also be used to automate the management functions through shell scripts and batch files.

CLI commands for many functions are server based and are provided with the host agent.

The remaining CLI commands are web-based and are provided with the software that runs in storage system service processors (SPs).

Configuration and Management of storage-system using Navisphere CLI:

The following steps are involved in configuring and managing the storage system (CX series, AX series) using CLI:

  • Install the Navisphere on the CLI on the host that is connected to the storage. This host will be used to configure the storage system.
  • Configure the Service processor (SP) agent on the each SP in the storage system.
  • Configure the storage system with CLI
  • Configuring and managing remote mirrors (CLI is not preferred to manage mirrors)

The following are two types of Navisphere CLI:

  1. Classic CLI is old version and it does not support any new features. But, this will still get the typical storage array jobs done.
  2. Secure CLI is most secured and preferred interface. Secure CLI includes all the commands as Class CLI with additional features. It also provides role-based authentication, audit trails of CLI events, and SSL-based data encryption.

Navisphere CLI is available for various OS including Windows, Solaris, Linux, AIX, HP-UX, etc.

Two EMC CLARiiON Navisphere CLI commands:

  1. naviseccli (Secure CLI) command sends storage-system management and configuration requests to a storage system over the LAN.
  2. navicli (Classic CLI) command sends storage-system management and configuration requests to an API (application programming interface) on a local or remote server.

In storage subsystem (CLARiiON, VNX, etc), it is very important to understand the following IDs:

  • LUN ID – The unique number assigned to a LUN when it is bound. When you bind a LUN, you can select the ID number. If you do not specify the LUN ID then the default LUN ID bound is 0, 1 and so on..
  • Unique ID – It usually refers to the storage systems, SP’s, HBAs and switch ports. It is WWN (world wide Name) or WWPN (World wide Port Name).
  • Disk ID 000 (or 0_0_0) indicates the first bus or loop, first enclosure, and first disk, and disk ID 100 (1_0_0) indicates the second bus or loop, first enclosure, and first disk.
  1. Create RAID Group

The below command shows how to create a RAID group 0 from disks 0 to 3 in the Disk Processor Enclosure(DPE).

naviseccli –h H1_SPA createrg 0  0_0_0   0_0_1   0_0_2  0_0_3

In this example , -h Specifies the IP address or network name of the targeted SP on the desired storage system. The default, if you omit this switch, is localhost.

Since each SP has its own IP address, you must specify the IP address to each SP. Also a new RAID group has no RAID type (RAID 0, 1, 5) until it is bound. You can create more RAID groups 1, 2 and so on using the below commands:

naviseccli –h H1_SPA createrg 1  0_0_4 0_0_5 0_0_6


naviseccli –h H1_SPA createrg 2 0_0_7 0_0_8

This is similar to how you create raid group from the navsiphere GUI.

  1. Bind LUN on a RAID Group

In the previous example, we created a RAID group, but did not create a LUN with a specific size.

The following examples will show how to bind a LUN to a RAID group:

navisecli -h H1_SPA bind r5 6 -rg 0  -sq gb -cap 50

In this example, we are binding a LUN with a LUN number/LUN ID 6 with a RAID type 5 to a RAID group 0 with a size of 50G. –sq indicates the size qualifier in mb or gb. You can also use the options to enable or disable rc=1 or 0(read cache), wc=1 or 0 (write cache).

  1. Create Storage Group

The next several examples will shows how to create a storage group and connect a host to it.

First, create a stroage group:

naviseccli -h H1_SPA storagegroup -create -gname SGroup_1

  1. Assign LUN to Storage Group

In the following example, hlu is the host LUN number. This is the number that host will see from its end. Alu is the array LUN number, which storage system will see from its end.

naviseccli -h H1_SPA storagegroup -addhlu -gname SGroup_1 -hlu 12 -alu 5

  1. Register the Host

Register the host as shown below by specificing the name of the host. In this example, the host server is elserver1

naviseccli -h H1_SPA elserver1 register

  1. Connect Host to Storage Group

Finally, connect the host to the storage group as shown below by using -connecthost option as shown below. You should also specify the storagegroup name appropriately.

naviseccli -h H1_SPA storagegroup -connecthost -host elserver1 -gname SGroup_1

  1. View Storage Group Details

Execute the following command to verify the details of an existing storage group.

naviseccli  -h H1_SPA storagegroup –list –gname SGroup_1

Once you complete the above steps, your hosts should be able to see the newly provisioned storage.

  1. Expand RAID Group

To extend a RAID group with new set of disks, you can use the command as shown in the below example.

naviseccli -h H1_SPA chgrg 2 -expand 0_0_9  0_1_0 -lex yes -pri high

This extends the RAID group with the ID 2 with the new disks 0_0_9 & 0_1_0 with lun expansion set to yes and priority set to high.

  1. Destroy RAID Group

To remove or destroy a RAID group, use the below command.

naviseccli -h H1_SPA destroyrg 2  0_0_7 0_0_8 0_0_9 0_1_0 –rm yes –pri high

This is similar to how you destroy raid group from the navisphere GUI.

  1. Display RAID Group Status

To display the status RAID group with ID 2 use the below command.

naviseccli -h H1_SPA getrg 2 -lunlist

  1. Destroy Storage Group

To destroy a storage group called SGroup_1, you can use the command like below:

naviseccli -h H1_SPA storagegroup -destroy -gname SGroup_1

  1. Copy Data to Hotspare Disk

The naviseccli command initiates the copying of data from a failing disk to an existing hot spare while the original disk is still functioning.

Once the copy is made, the failing disk will be faulted and the hotspare will be activated. When the faulted disk is replaced, the replacement will be copied back from the hot spare.

naviseccli –h H1_SPA copytohotspare 0_0_5  -initiate

  1. LUN Migration

LUN migration is used to migrate the data from the source LUN to a destination LUN that has more improved performance.

naviseccli migrate –start –source 6 –dest 7 –rate low

Number 6 and 7 in the above example are the LUN IDs.

To display the current migration sessions and its properties:

naviseccli migrate –list

  1. Create MetaLUN

MetaLUN is a type of LUN whose maximum capacity is the combined capacities of all LUNs that compose it. The metaLUN feature lets you dynamically expand the capacity of a single LUN in to the larger capacity called a metaLUN. Similar to LUN, a metaLUN can belong to storage group and can be used for Snapview, MirrorView and SAN copy sessions.

You can expand a LUN or metaLUN in two ways — stripe expansion or concatenate expansion.

A stripe expansion takes the existing data on the LUN or metaLUN, and restripes (redistributes) it across the existing LUNs and the new LUNs you are adding.

The stripe expansion may take a long time to complete. A concatenate expansion creates a new metaLUN component that includes the new LUNs and appends this component to the end of the existing LUN or metaLUN. There is no restriping of data between the original storage and the new LUNs. The concatenate operation completes immediately

To create or expand a existing metaLUN, use the below command.

naviseccli -h H1_SPA metalun -expand -base 5 -lun 2 -type c -name newMetaLUN-sq gb –cap 50G

This creates a new meta LUN with the name “newMetaLUN” with the meta LUN ID 5 using the LUN ID 2 with a 50G concatenated expansion.

  1. View MetaLUN Details

To display the information about MetaLUNs, do the following:

naviseccli -h H1_SPA metalun –info

The following command will destroy a specific metaLUN. In this example, it will destory metaLUN number 5.

naviseccli –h H1_SPA metalun –destroy –metalun 5

Add your comment



استوریج های سری VNX شرکت EMC


Home, Optimizer, Benchmarks, Server Systems, Systems Architecture, Processors, Storage,
Storage Overview, System View of Storage, SQL Server View of Storage, File Layout,

PCI-ESASFCHDDSSD Technology RAID ControllersDirect-Attach,
SAN, Dell MD3200, EMC CLARiiON AX4, CLARiiON CX4, VNX, V-Max,
HP P2000, EVA, P9000/VSP, Hitachi AMS
SSD products: SATA SSDs, PCI-E SSDs , Fusion iO , other SSD

Updated 2013-10

Update 2013-10
A link to Storage Review EMC Next Generation VNX Series Released … by Brian Beeler. While the preliminary slidedecks mention VNX2, the second generation VNX is jsut VNX. No 2 at the end.

In the table below, the second generation VNX specifications (per SP except as noted). The VNX5200 will come out next year?

VNX5200 VNX5400 VNX5600 VNX5800 VNX7600 VNX8000
Max FE ports 12? 16? 20 20 20 40
Max UltraFlex I/O 2 4 5 5 5 11
embedded I/O 2 SAS? 2 SAS 2 SAS 2 SAS 2 SAS none
Max SAS 2 6 6 6 16
Max FAST Cache 600GB 1TB 2TB 3TB 4.2TB 4.2TB
Max drive 125 250 500 750 1000 1500*
Xeon E5 1.2GHz 4c 1.8GHz 4c 2.4GHz 4c 2.0GHz 6c 2.2GHz 8c 2×2.7G 8c
Memory 16GB 16GB 24GB 32GB 64GB 128GB
Cores 4 4 4 6 8 16


Below is the back-end of the VNX5400 DPE. The DPE has 2 SPs. Each SP has 5 slots? One the top are the power supply, battery backup unit (BBU) and SAS module with 2-ports. One the bottom, the first module is for management.




Below is the EMC VNX 8000 SPE back-end


I/O module options for the VNX are: quad-port 8Gb/s FC, quad-port 1Gb/s Ethernet, dual-port 10GbE. The VNX 5600 and up can also support a quad-port 6Gb/s SAS module.


Updated 2013-02

While going through the Flash Management Summit 2012 slide decks, I came across the session Flash Implications in Enterprise Storage Designs by Denis Vilfort of EMC, that provided information on performance of the CLARiiON, VNX, a VNX2 and VNX Future.

A common problem with SAN vendors is that it is almost impossible to find meaningful performance information on their storage systems. The typical practice is to cited some meaningless numbers like IOPS to cache or the combined IO bandwidth of the FC ports, conveying the impression of massive IO bandwidth, while actually guaranteeing nothing.

VNX (Original)

The original VNX was introduced in early 2011? The use of the new Intel Xeon 5600 (Westmere-EP) processors was progressive. The decision to employ only a single socket was not.


Basic IO functionality does not require huge CPU resources. But the second socket would double memory bandwidth, which is necessary for driving IO. Data read from storage must first be written to memory before being sent to host? The second processor would also better support a second IOH. Finally, the additional CPU resources would support the value-add features that SAN vendors so desparately try to promote.

EMC did provide the table below on their VNX mid-range systems in the document “VNX: Storage Technology High Bandwidth Application” (h8929) showing the maximum number of front-end FC and back-end SAS channels along with the IO bandwidths for several categories. This is actually unusual for a SAN storage vendor, so good for EMC. Unfortunately, there is no detailed explanation of the IO patterns for each category.


Now obviously the maximum IO bandwidth can be reached in the maximum configuration, that is with all IO channels and all drive bays populated. There is also no question that maximum IO bandwidth requires all back-end IO ports populated and a sufficient number of front-end ports populated. (The VNX systems may support more front-end ports than necessary for configuration flexibility?)

However, it should not be necessary to employ the full set of hard disks to reach maximum IO bandwidth. This is because SAN systems are designed for capacity and IOPS. There are Microsoft Fast Track Data Warehouse version 3.0 and 4.0 documents for the EMC VNX 5300 or 5500 system. Unfortunately Microsoft has backed away from the bare table scan test of disk rate in favor of a composite metric. But it does seem to indicate that 30-50MB/s per disk is possible in the VNX.

What is needed is a document specifying the configuration strategy for high bandwidth specific to SQL Server. This includes the number and type of front-end ports, the number of back-end SAS buses, the number of disk array enclosures (DAE) on each SAS bus, the number of disks in each RAID group and other details for each significant VNX model. It is also necessary to configure the SQL Server database file layout to match the storage system structure, but that should be our responsibility as DBA.

It is of interest to note that the VNX FTDW reference architectures do not employ Fast Cache (flash caching) and (auto) tiered-storage. Both of these are an outright waste of money on DW systems and actually impedes performance. It can make good sense to employ a mix of 10K/15K HDD and SSD in the DW storage system, but we should use the SQL Server storage engine features (filegroups and partitioning) to place data accordingly.

A properly configured OLTP system should also employ separate HDD and SSD volumes, again using of filegroups and partitioning to place data correctly. The reason is that the database engine itself is a giant data cache, with perhaps as much as 1000GB of memory. What do we really expect to be in the 16-48GB SAN cache that is not in the 1TB database buffer cache? The IO from the database server is likely to be very misleading in terms of what data is important and whether it should be on SSD or HDD.

CLARiiON, VNX, VNX2, VNX Future Performance

Below are performance characteristics of EMC mid-range for CLARiiON, VNX, VNX2 and VNX Future. This is why I found the following diagrams highly interesting and noteworthy. Here, the CLARiiON bandwidth is cited as 3GB/s and the current VNX as 12GB/s (versus 10GB/s in the table above).


I am puzzled that the VNX is only rated at 200K IOPS. That would correspond to 200 IOPS per disk and 1000 15K HDDs at low queue depth. I would expect there to be some capability to support short-stroke and high-queue depth to achieve greater than 200 IOPS per 15K disk.

The CLARiiON CX4-960 supported 960 HDD. Yet the IOPS cited corresponds to the queue depth 1 performance of 200 IOPS x 200 HDD = 40K. Was there some internal issue in the CLARiiON. I do recall a CX3-40 generating 30K IOPS over 180 x 15K HDD.

A modern SAS controller can support 80K IOPS, so the VNX 7500 with 8 back-end SAS buses should handle more than 200K IOPS (HDD or SSD), perhaps as high as 640K? So is there some limitation in the VNX storage processor (SP), perhaps the inter-SP communication? or a limitation of write-cache which requires write to memory in both SP?


Below (I suppose) is the architecture of the new VNX2. (Perhaps VNX2 will come out in May with EMC World?) In addition to transitioning from Intel Xeon 5600 (Westmere) to E5-2600 series (Sandy Bridge EP), the diagram indicates that the new VNX2 will be dual-processor (socket) instead of single socket on the entire line of the original VNX. Considering that the 5500 and up are not entry systems, this was disappointing.


VNX2 provides 5X increase in IOPS to 1M and 2.3X in IO bandwidth to 28GB/s. LSI mentions a FastPath option that dramatically increases IOPS capability of their RAID controllers from 80K to 140-150K IOPS. My understanding is that this is done by completely disabling the cache on the RAID controller. The resources to implement caching for large array of HDDs can actually impede IOPS performance, hence caching is even more degrading on an array of SSDs.

The bandwidth objective is also interesting. The 12GB/s IO bandwidth of the original VNX would require 15-16 FC ports at 8Gbps (700-800MBps per port) on the front-end. The VNX 7500 has a maximum of 32 FC ports, implying 8 quad-port FC HBAs, 4 per SP.

The 8 back-end SAS busses implies 4 dual-port SAS HBAs per SP? as each SAS bus requires 1 SAS port to each SP? This implies 8 HBAs per SP? The Intel Xeon 5600 processor connects over QPI to a 5220 IOH with 32 PCI-E gen 2 lanes, supporting 4 x8 and 1×4 slots, plus a 1×4 Gen1 for other functions.

In addition, a link is needed for inter-SP communication. If one x8 PCI-E gen2 slot is used for this, then write bandwidth would be limited to 3.2GB/s (per SP?). A single socket should only be able to drive 1 IOH even though it is possible to connect 2. Perhaps the VNX 7500 is dual-socket?

An increase to 28GB/s could require 40 x8Gbps FC ports (if 700MB/s is the practical limit of 1 port). A 2-socket Xeon E5-2600 should be able to handle this easily, with 4 memory channels and 5 x8 PCI-E gen3 slots per socket.

VNX Future?

The future VNX is cited as 5M IOPS and 112GB/s. I assume this might involve the new NVM-express driver architecture supporting distributed queues and high parallelism. Perhaps the reason both VNX2 and VNX Future are described is that the basic platform is ready but not all the components to support the full bandwidth?


The 5M IOPS should be no problem with an array of SSDs, and the new NVM express architecture of course. But the 112GB/s bandwidth is curious. The number of FC ports, even at a future 16Gbit/s is too large to be practical. When the expensive storage systems will finally be able to do serious IO bandwidth, it will also be time to ditch FC and FCOE. Perhaps the VNX Future will support infini-band? The puprose of having extreme IO bandwidth capability is to be able to deliver all of it to the database server on demand. If not, then the database server should have its own storage system.

The bandwidth is also too high for even a dual-socket E5-2600. Each Xeon E5-2600 has 40 PCI-E gen3 lanes, enough for 5 x8 slots. The nominal bandwidth per PCIe G3 lane is 1GB/s, but the realizable bandwidth might be only 800MB/s per lane, or 6.4GB/s. A socket system in theory could drive 64GB/s. The storage system is comprised of 2 SP, each SP being a 2-socket E5-2600 system.

To support 112GB/s each SP must be able to simultaneously move 56GB/s on storage and 56GB/s on the host-side ports for a total of 112GB/s per SP. In addition, suppose the 112GB/s bandwidth for read, and that the write bandwidth is 56GB/s. Then it is also necessary to support 56GB/s over the inter-SP link to guarantee write-cache coherency (unless it has been decided that write caching flash on the SP is stupid).

Is it possible the VNX Future has more than 2 SP’s? Perhaps each SP is a 2-socket E5-4600 system, but the 2 SPs are linked via QPI? Basically this would be a 4-socket system, but running as 2 separate nodes, each node having its own OS image. Or that it is a 4-socket system? Later this year, Intel should be releasing an Ivy Bridge-EX, which might have more bandwidth? Personally I am inclined to prefer a multi-SP system over a 4-socket SP.

Never mind, I think Haswell-EP will have 64 PCIe gen4 lanes at 16GT/s. The is 2GB/s per lane raw, and 1.6GB/s per lane net, 12.8GB/s per x8 slot and 100GB/s per socket. I still think it would be a good trick if one SP could communicate with the other over QPI, instead of PCIe. Write caching SSD at the SP level is probably stupid if the flash controller is already doing this? Perhaps the SP memory should be used for SSD metadata? In any case, there should be coordination between what each component does.


It is good to know that EMC is finally getting serious about IO bandwidth. I was of the opinion that the reason Oracle got into the storage business was that they were tired of hearing complaints from customers resulting from bad IO performance on the multi-million dollar SAN.

My concern is that the SAN vendor field engineers have been so thoroughly indoctrinated in the SaaS concept that only capacity matters while having zero knowledge of bandwidth, that they are not be able to properly implement the IO bandwidth capability of the existing VNX, not to mention the even higher bandwidth in VNX2 and Future.

unsorted misc






EMC VNX Early 2011?

VNX came out in early 2011 or late 2010? All VNX models use the Xeon 5600 processors, ranging from 2.13 to 2.8GHz, and four to six cores (actually from 1.6GHz and 2 cores?). The 5100, 5300 and 5500 are comprised of two Disk-processor enclosures (DPE) that house both the storage processors and the first tray of disks. The 5700 and 7500 models are comprised of Storage-processor enclosures (SPE) that house only the storage processors. Two DPE or SPE comprise an Array.

VNX 5100 VNX 5300 VNX 5500 VNX 5700 VNX 7500
Max Drives 75 125 250 500 1000
Enclosure 3U Disk + SP 3U Disk + SP 3U Disk + SP 2U SP 2U SP
DAE Options 25 x 2.5″-2U
15 x 3.5″-3U
25 x 2.5″-2U
15 x 3.5″-3U
25 x 2.5″-2U
15 x 3.5″-3U
25 x 2.5″-2U
15 x 3.5″-3U
60 x 3.5″-4U
25 x 2.5″-2U
15 x 3.5″-3U
60 x 3.5″-4U
Memory per Array 8GB 16GB 24GB 36GB 48GB
Max UltraFlex IO
Modules per Array
0 4 4 10 10
Embedded IO Ports
per Array
8 FC & 4 SAS 8 FC & 4 SAS 8 FC & 4 SAS
Max FC Ports
per Array
8 16 16 24 32
SAS Buses
(to DAEs)
2 2 2 or 6 4 4 or 8
Freq 1.6GHz 1.6GHz 2.13GHz 2.4GHz 2.8GHz
cores 2 4 4 4 6
Mem/DPE 4GB 8GB 12GB 18GB 24GB

The VNX front-end is FC with options for iSCSI. The back-end is all SAS (in the previous generation, this was FC). The 5100-5500 models have 4 FC ports and 1 SAS bus (2 ports) embedded per DPE, for 8 FC and 2 SAS busses per array. The 5100 does not have IO expansion capability. The 5300 and 5500 have 2 IO expansion ports per DPE, for 4 total in the array. The 5300 only allows front-end IO expansion, while the 5500 allows expansion on both front-end and back-end IO.

The 5300 and higher VNX models can also act as file servers with X-blades in the IO expansion slots. This capability is not relevent to high-performance database IO and is not considered here.

Disk-array enclosure (DAE) options are now 25 x 2.5″ in 2U, 15 x 3.5″ in 3U or a 60 x 3.5″ in 4U. The hard disk long dimemsion is vertical, the 1″ disk height is aligned along the width of the DAE for 12 across, and this is 5 deep.

An UltraFlex IO Module attaches to a PCI-E slot? (x8?). Module options are quad-port FC (upto 8Gbps), dual-port 10GbE, or quad-port 1GbE, or 2 SAS busses (4-ports). So a module could be 1 SAS bus (2 ports), 4 FC ports etc?

Each SAS port is 4 lanes at 6Gbp/s and 2 ports make 1 “bus” with redundant paths.

The first 4 physical disks reserves 192GB per disk.

There is an EMC document h8929-vnx-high-bandwidth-apps-ep with useful information. more later. The diagram below is from the EMC VNC document. The VNX storage engine core is a Westmere processor (1 or 2?) with 3 memory channels, and IO adapters on PCI-E gen 2. The backend is SAS, and the front-end to host can be FC, FCoE or iSCSI.

Below is the VNX System architecture from an EMC slidedeck titled “Introducing VNX Series”. Note EMC copyright, so I suppose I should get permission to use? In block mode, only the VNX SP is required. In file mode, up to four X-Blades can be configured?

Below from: Introducing VNX Series, Customer Technical Update


Below from h8929


As far as I can tell, the VNX models have a single Xeon 5600 processor (socket). While it may not take much CPU-compute capability to support a SAN storage system, there is a significant difference in the IO capability with 2 processor sockets populated (6 memory channels instead of 3), noting that IO must be writen to memory from the inbound side, then read from memory to the outbound side.

VNX 5100 VNX 5300 VNX 5500 VNX 5500* VNX 5700 VNX 7500
Backend SAS Buses 2 2 2 6* 4 4 or 8 Max Frontend FC 8 16 16 16 24 32 DSS Bandwidth (MB/s) 2300 3600 4200 4200 6400 7300 DW Bandwidth (MB/s) 2000 3200 4200 6400 6400 10000 Backup BW – Cache bypass mode 700 900 1700 1900 3300 7500 Rich Media BW 3000 4100 5700 5700 6200 9400

Note: * VNX 5500 Hi-BW option consumes all the flex-IO modules, and bandwidth is limited by FC front-end?


The SAS IO expansion module adds 4 SAS ports for a total of 6 ports, since 2 are integrated. However, only a total of 4 ports (2 busses) are used per DPE.

Full Data Warehouse bandwidth requires at least 130 x 15K SAS drives.


h8177 says:
VNX5100 can support 1,500MB/s per DPE or 3,000MB/s for the complete 5100 unit.
VNX5300 can support 3,700MB/s for the complete unit.
VNX5500 can support 4,200MB/s for the complete unit on integrated back-end SAS ports, and 6,000MB/s with additional back-end SAS ports.

Flare 31.5 talks about the VNX5500 supporting additional front-end and back-end ports in the 2 expansion slots. To achieve the full 6,000MB/s, the integrated 8Gbps FC ports must be used in combination with additional Front-end ports in one of the expansion slots


The Cisco/EMC version of the SQL Server Fast Track Data Warehouse employs one VNX 5300 with 75 disks and two 5300’s with a total of 150 disks, each VNX with 4 x 10Gb FCoE connections. The throughput is 1985 for the single 5300 and 3419MB/s for two. This is well below the list bandwidth of 3GB/s+ for the VNX5300, which may have required 130 disks?

Of the 75 disks on each 5300, only 60 are allocated to data. So the 1985MB/s bandwidth corresponds to 33MB/s per disk, well below the Microsoft FTDW reference of 100MB/s per disk. The most modern 15K 2.5in hard drives are rated for 202MB/s on the outer tracks (Seagate Savvio 15K.3). The Seagate Savvio 10K.5 is rated for 168MB/s on the outer tracks. With consideration for the fact that perfect sequential placement is difficult to achieve, the Microsoft FTDW target of 100MB/s per disk or even a lower target of 50MB/s per disk is reasonable, but 33MB/s per disk is rather low.


Data warehouse IO is 512KB random read.
DSS is 64KB sequential read.
Backup is 512KB sequential write.
Rich media is 256KB sequential read.

Deploying EMC VNX Unified Storage Systems for Data Warehouse Applications (Dec 2011)
Introduction to the EMC VNX Series, A Detailed Review (Sep 2011)

Other EMC documents h8297 Cisco Reference Configurations for Microsoft SQL Server 2008 R2 Fast Track Data Warehouse 3.0 with EMC VNX5300 Series Storage Systems
h8929 VNX: Storage Technology High Bandwidth Applications



در یک کامپیوتر استوریج به محلی اطلاق می شود که داده ها در آن به فرمهای الکترومغناطیسی و یا نوری نگهداری می شوند و برای استفاده در اختیار پردازنده سیستم قرار می گیرد.

دو مورد استفاده از استوریج ها که بصورت های تجهیزات I/O به سیستم وصل می شوند هارد دیسک ها و سیستم های Tape می باشند.

البته این دو Device به عنوان تجهیزات جانبی به سیستم وصل می شوند و منایع ذخیره سازی دیگری نیز مانند مموری و استوریج داخلی بر روی خود سیستم ها قرار می گیرند.

در بیشتر اوقات استوریج به دو دسته ذیل تقسیم بندی می شود:

1- Primary Storage: که وظیفه نگهداری داده ها در حافظه RAM و یا بر روی حافظه موجود در خود پردازنده Cache L1 را بر عهده دارد.

2- Secondary Storage: وظیفه نگهداری از اطلاعات بر روی هارد دیسک ها و Tape ها و دیگر تجهیزاتی که عملیات I/O را انجام می دهند را دارد.





مفاهیم استوریج

Storage Fundamentals N

lass description

IBM Top Gun Virtual Learning (TGVL): Storage Fundamentals is a basic (100) level virtual class that addresses fundamental concepts of storage that must be understood in order to effectively sell IBM System Storage solutions. These fundamentals are prerequisite knowledge for attending IBM System Storage Information Infrastructure Top Gun.

This class does NOT contain product-specific information.


The IBM TGVL: Storage Fundamentals class will be held on two consecutive days, approximately four hours each day. This is a total of two 1/2 days.


The audience for this class is:

Note: Although this course is available to students worldwide, please be aware that all topics will be presented in English.


The objective for this class is to:

  1. To provide the student with fundamental knowledge of storage concepts and terminology
  2. To position the student for further training on IBM System Storage products and solutions

Note: this course does not cover storage products. It is focused on the conceptual “building blocks” necessary for any storage seller.


Prerequisite reading (whitepapers, solution briefs, etc.) may be assigned.


Day Topic
Day 1 Class Overview and Objectives

Disk Concepts

How Servers Talk to Storage

What is Disk Virtualization?

Day 2 The Basics of Backup and Recovery

Introduction to Point in Time Copy

Introduction to Disk Mirroring


The class location is your office – no travel. The class will be delivered via a live internet-based virtual classroom (see Schedule). Subsequently, the class will be made available for replay.


This class has no enrollment fee.


Scheduled classes: