Yep -- there's a serial port on the back just as you'd like along with an adapter and nice long serial cable that should come in the box.

On first boot, the filer will go directly into the "setup" script -- a quite nice text-driven setup script that covers all the major stuff. Even better, you can run it from the console later if you want just by typing "setup" (you can adjust everything you do in "setup" manually but sometimes it's just nicer to walk back through it).

Be sure to look in TR-3428 for optimal settings on both the NetApp & VMware sides.

Phew....those are some pretty big questions that deserve quite a bit of discussion.

In brief....

1. A 2050A is actually 2 separate filer heads in an active/active cluster arrangement. In a failover scenario, one head brings up the other head's identity. This gives the benefit of having the power of both heads but does mean that you have to configure both heads individually and each head needs its own separate set of disks.
2. Failover is built into the 2050 chassis....cabling doesn't affect it hugely. If you don't have any disks, I'm not sure what you'd want/need the cables for (they're not SCSI cables I'm pretty sure....like fiber jumpers?).
3. When I'm doing CIFS & iSCSI on a 2050, I usually put in the 2 port add-on card actually and do a 2-NIC team for CIFS and a 2-NIC team for iSCSI/NFS (if using NFS for VMware). In your scenario, splitting CIFS and iSCSI/NFS between the two heads could make sense.
4. You'll need to dedicate disks to each head -- 6 disks per head if you split them evenly. When you subtract a single hot spare (once again per head), you're down to 5 disks that you can use in a RAID DP arrangement -- meaning you'll have about 2.05 TB usable on each head (after parity disks, WAFL overhead, etc.).
5. • Note: you could dedicate all the disks to one head to get more space (6.14 TB usable total with one hot spare)....you'd lose HA at that point of course.

Now, those are very short answers....this could be a MUCH longer discussion and to be horribly honest is one that probably should have happened before the sale. What I'd recommend is seeing if you could have some sit-down time with the partner who sold you the gear to discuss recommendations for setup.

I think the comment of not using aggr0 for production is a poor comment (sorry, no offence meant). On a 2050 you haven't got exactly buckets of disks to play with, and partitioning off 3 of them for a 20g volume is a total waste. On your system, you simply don't have enough disks for 2 aggregates on each head anyway! Expand the existing aggr0 and make the full use of all those spindles. Be careful if you do this on the command line as it doesn't warn you about hot spares! Do it from the filer view and it'll force you to keep 2 hot spares. On each controller, keep the default name of aggr0 as it'll make it easier to reference, and it'll make you understand more that they are 2 independent storage arrays. Perhaps rename the aggr0 to the hostname (aggr rename aggr0 hostname_aggr0) to make it clearer for you to understand.

I'd also recommend reducing the vol0 size, it's always way too big (vol size vol0 20g). You can do this hot, and 20g is plenty big enough for a 2050.

Create as few aggregates as possible, and leverage as many spindles as possible. This will give you the best performance possible, and on a 2050, the spindles are more likely to be your bottleneck on smaller workloads. Much better to make the head unit do all the hard work.

I am also working on deloyment of a FAS2050 with 20 x 300 GB SAS 15K drives .  The array will only use FC and serve luns to a 2 node ESX cluster.

I wanted to get opinions / comments on the following deployment decisions...

I opted to use Controller B as an Active Controller which will only be utilized in a failure so I changed it to Raid-4 after a quite a bit of research and pestering of our SE.  I am hoping that going for  a wider spindle spread under my production Aggregate in Controller A is better suited for the ESX workload then 2 smaller Aggregates under 2 Controllers.   I also want to provision from a single interface.  I had some hesitation about using Raid-4 at first because I was told it would require that provisioned luns be taken offline for upgrades of disk firmware but after some research it looks like this is is required when using any SAS or ATA disk chassis even when configured with Raid-DP.

Node A Raid-DP Active  -  Resized Root Flex Volume to 64 GB from 224 GB

3.04 TB Available for Production Volumes

17 - Disks

2 Parity

14 DATA

1 Hot Spare

Node B Raid-4 Active ( only used durring failure of Node A )

3 Disk

1 Parity

1 Data

1 Hotspare

Chris,

Thank you for the response.  I am looking for general opinions as this is my first Netapp array.  I will be migrating a handful of Windows Servers one of which is large Windows file server which is about 2.5 TB of data spread across 4 Windows Volumes on a Clariion CX300. The main reason for moving to Netapp was to leverage array based replication.

I have worked with EMC arrays for about 4 years, again I am new to Netapp, but in my EMC experiences I have rarely seen high storage processor or Front end utilization issues for the MS Windows Application workloads we run.  Utilization issues in the past have been dues to underlying spindle count.

In regards to the firmware upgrades of SAS disk it seems like you are speaking from experience which I am lacking on Netapp but I found this in the Data Ontap 7.3 upgrade guide Page 33 which I interpreted as a SAS / SATA shelf limitation.

When not to use  nondisruptive upgrades

You need to update  firmware for SAS-based,  AT-FC-based, AT-FC2-based, or AT-FCX-based disk

shelves on your  system.  Client services might  encounter delays accessing data when disk shelf firmware is updated to  SAS,

AT-FC, AT-FC2, or AT-FCX  modules. To prevent data loss, all session-oriented services must  be

terminated before you  begin an update procedure.

Here is a more detailed summary of what I am working with...

2 –  FAS2050 arrays

2 Host  ESX 3.5 U3 Cluster Production – Leverage Existing 3 Node ESX cluster for  DR

2 –5   Guest OS Windows 2003 Standards SP2 – RDM Virtual Machines

FAS2050  will serve up FC luns to a 2 node ESX cluster hosting Windows Virtual Machines.   All VMs will use RDM (Raw Device Mapping) Luns for Windows OS “C:\” and Data Volumes, ie “D:\”, “E:\”, etc…  A small Netapp Volume  will be created for a single Netapp lun which will only be configured as a VMFS Datastore used  only for Virtual Machine Config files and a small VMDK lun for each Virtual  Machine.  The VMDK lun will be configured as dedicated Windows X:\ volume with a 2^nd 4095 MB  Windows Page file with in the Guest OS.  This Netapp Volume will not be replicated.  All Netapp RDM luns  provisioned for each specific VM will be created in their own Netapp volume and  replicated with Snapmirror to another FAS2050 in the DR site.  The target  FAS2050 will have a similar configuration with the underlying read-only  replicated Netapp Volumes containing the DR copy of the production Virtual Machines underlying RDMs.  The DR Luns will be   pre-provisioned configured in Virtual Center with resources matching production but which will be in a powered OFF state ready for a failover if  needed.  The paramount requirement is replication.

I'd actually hoped to reply to this sooner....overtaken by events and I think you've got most everything out on the table.

The only comment I wanted to add was that I've been steering away from selling FAS20x0c boxes with just internal drives....simply given it makes the aggregate setup annoying (stuck with trade-offs regardless).

So yes, it's money....but I like to do one (or more) external shelves with the external disk controlled by one head and the internal disk controlled by one head. Just makes for nice isolation and also allows for good aggregate sizing/usable space.

For example, I'll be setting up a 2050c in the next month with (2) external shelves of 300 GB 10k FC drives and (12) 1 TB internal drives -- makes the aggregate setup nice and simple. :-)