Ibm system storage n series with multi store and snapmover redp4170

Redbooks Paper
Alex Osuna
Chrisanthy Carlane

IBM System Storage N Series with
MultiStore and SnapMover

Overview
This IBM® Redpaper describes how IBM System Storage™ N series with
MultiStore® and SnapMover® technology enables companies to better manage,
consolidate, migrate, and replicate critical data with minimal effort and maximum
return. It discusses both MultiStore and SnapMover technology as well migration
and integration topics.

© Copyright IBM Corp. 2007. All rights reserved. ibm.com/redbooks 1

Virtual storage systems with System Storage N series
The storage system hardware is made up of CPUs, network cards, Fibre
Channel controllers, power supplies, disk drives, and so forth. You can use
System Storage N series with MultiStore software to effectively partition and
dynamically assign a storage system's storage and networking resources to
virtual storage systems to virtualize the physical resources and move them
beyond the logical architectural limitations inherent in a single physical storage
system. You can create and host up to 33 virtual storage systems, known as
Vfiler™, on a storage system, each serving data as a storage system does.
Other network computers communicate with virtual storage systems as they
would with any other file server.

Some Vfiler facts include:
Vfilers appear in the network as discrete multiprotocol file servers and are
accessed as are any other Windows® or UNIX® file servers.
Companies can deploy a Vfiler into full production in a matter of minutes with
only a few software commands.
Each Vfiler independently controls access to its storage resources according
to its security settings and permissions assigned to groups and users by
Windows or UNIX system administrators.
Network settings such as IP addresses, IPspaces associations, DNS
information, Windows domain, and other settings are explicitly assigned to
each Vfiler.
Virtual storage systems and their resources can be replicated or moved to
other storage systems, dramatically simplifying data consolidation, migration,
and disaster recovery.
Resources can be added, removed, or moved between virtual storage
systems at any time.

2 IBM System Storage N Series with MultiStore and SnapMover

Figure 1 describes a storage system that also hosts three virtual storage
systems. The virtual storage systems are assigned resources from the hosting
storage system, which still functions as a normal storage system. The virtual
storage system in Figure 1 appears in the network as vfiler2.ibm.com,
vfiler3.ibm.com, and vfiler4.ibm.com.

Figure 1 Hosting storage system and three virtual storage systems

In Figure 1, the hosting storage system and each Vfiler can be a member of the
same UNIX NIS domain, ibm.com, the same Microsoft® Active Directory®
domain ibm.com, and the same DNS domain ibm.com. However, each Vfiler
could be created in a separate IP space and assigned membership in different
security domains and DNS namespaces.

Business value of virtual storage systems
Different administrators, groups, or organizations might be responsible for
managing the hosting storage system or each Vfiler. The hosting storage system
and certain aspects of each Vfiler can all be managed independently, allowing
one department or organization to manage the hosting storage system and
others to manage their own data independently and securely.

The hosting storage system administrator or storage engineer is responsible for
managing volumes, disks, RAID groups, Snapshots, and backup. A Vfiler
administrator is responsible for managing Windows or UNIX security, file system
permissions, and antivirus settings for their organization’s Vfiler. Vfiler

IBM System Storage N Series with MultiStore and SnapMover 3

administrators for different organizations do not have permission to access other
virtual storage systems unless explicitly allowed, which allows for more flexible
management policies and greater security as illustrated in Figure 2.

Figure 2 Managing MultiStore with FilerView®

Administrators can manage virtual storage systems using the command line
interface (CLI), the System Storage N series FilerView Web-based application,
or the centralized Operations Manager framework. Some advanced tasks, such
as those related to the SnapMirror® integrated disaster recovery and migration
functionality, must be managed using the CLI. Other tasks can be performed
using OS-level tools such as Active Directory. The Manage ONTAP solution also
allows programmatic management through Java™, C, and Perl toolkits. With
management options available to meet a range of needs, you can integrate
storage systems and MultiStore into a wide range of existing operations and
processes.

Administrators can create and destroy virtual storage systems easily as needed
to accommodate temporary projects or changing project priorities. It takes only
minutes to deploy a new Vfiler and even less time to destroy one that you no
longer need. No additional hardware needs to be deployed or managed. The
unprecedented ease and speed opens doors to more efficient operations and
project opportunities.


As business needs and workloads change, the administrator can migrate virtual
storage systems to ensure that critical projects receive the required level of
service and response times, while retired projects are still available online
through lower-tier storage. Using different storage system models in the same
infrastructure allows critical projects to run on the most powerful hardware, while
other projects are still available through smaller models. As priorities change, the
administrator can adjust the Vfiler deployments with just a few commands. This
flexibility leads to greater return on investment (ROI) and lower total cost of
ownership (TCO).

Storage management is virtualized, allowing the IT architect to separate many of
the logical needs of the infrastructure from the physical hardware that is used to
build it. Because less hardware is required, management and acquisition costs
can be reduced and adaptability improved.

In conjunction with SnapMover technology, a Vfiler can be migrated to another
storage system in seconds, with no data migration required and no interruptions
to the user. This migration is especially useful in dynamic computational
environments such as Grid Computing where huge computational demands
change rapidly as jobs and projects start and finish. The load balancing
capabilities provide opportunities for unprecedented application scaling
efficiencies.

MultiStore and SnapMover technologies can also be used with Vfiler migration
for system maintenance with no operational interruptions. Virtual storage
systems are migrated from a storage system needing maintenance to another
storage system. The maintenance is completed and the storage system
rebooted, and the Vfiler is migrated back to the original storage system all with
no interruptions or need to re-establish connections with the storage system if
using NFS or iSCSI. With SnapMover, the migrations take just seconds and do
not require additional network resources. Non-disruptive maintenance delivers
higher levels of service and allows more profitable operations by being able to
offer more stringent Service Level Agreements.

SnapMirror can be used to replicate virtual storage systems to one or more
target storage systems, where the mirrored virtual storage systems can be
quickly activated for disaster recovery purposes. This significantly simplifies
disaster preparedness and reduces the chances of anything else going wrong in
the stressful minutes following a disaster.


Configuring Vfiler
When a storage system is installed into equipment racks and the power, disk,
and network cables are installed, configuration is exceptionally quick and
straightforward. It is not unusual for experienced administrators to unpack a new
storage system and deploy it into production in about an hour. Virtual storage
systems are even easier because they can be created and deployed in minutes
with a few simple software commands. This section explains how to setup and
configure Vfiler.

Understanding the types of data in a virtual storage system
Virtual storage systems are associated with three different flavors of data.
Understanding the differences is important for understanding the remainder of
this paper. The three types of data include:
The first type of Vfiler information is metadata. This data is the information
that MultiStore associates with each Vfiler and uses to keep track of details
such as the Vfiler state, what protocols are licensed on the Vfiler, what
volumes are owned by the Vfiler, and so forth. The metadata is book-keeping
information needed to have the software function correctly.
The second type of information is configuration data. This data is kept in the
/etc directory of the Vfiler, just like configuration data for a physical storage
system. The configuration data is what gets defined during the Vfiler setup
process and can be updated along the way to reconfigure the Vfiler.
Configuration data typically deals with areas such as network addressing,
security authentication, and so forth.
The last type of data is the actual data that the Vfiler is storing and serving on
behalf of the hosts and applications using the storage system. This data is
information such as user files, database tables, and so forth. The stored data
is kept in the Data ONTAP® volumes owned by the Vfiler.

Keeping these distinctions clear will help you to better understand virtual storage
systems.

Depending on which protocols are licensed on the storage system, there are a
few simple steps that must be taken to configure a Vfiler after it is created. Each
Vfiler is set up like any storage system. The configuration files are all created in
the /etc directory of the Vfiler's primary storage unit when all of the prompts have
been answered and setup is complete.


There are three main processes that apply to setting up a Vfiler as listed in
Table 1.

Table 1 Processes to set up a Vfiler
Setup Process Information Supplied by the Administrator

The initial Vfiler setup Administration host or hosts
DNS domain name and server name information
NIS information (if applicable)
Root/administrative password

CIFS setup (for Windows WINS server addresses (if applicable)
environments) Root/administrative password
Type of user authentication (Windows NT4,
Windows 2000, Windows .NET domain, Workgroup
Authentication, /etc/passwd, or NIS-based)
If Windows domain authentication is selected, the
password with the permissions to create a domain
computer account

Enabling NFS By default, the NFS protocol is not turned on or
active. A single command activates NFS. (NFS
must already be licensed on the hosting storage
system.)


To configure Vfiler, follow these steps:
1. Go to Vfiler - Vfiler wizard menu, leave the check boxes selected, and click
Next as shown in Figure 3.

Figure 3 Choosing Vfiler Wizard Tasks


2. Specify the Vfiler name and storage path and click Next as shown in Figure 4.

Figure 4 Specify Vfiler name and storage path

If the storage path is a qtree, see Figure 5.

Figure 5 Specify Vfiler and qtree storage path


3. Specify network information or IPspace for the Vfiler, as shown in Figure 6.

Figure 6 Specify network information

4. Vfiler1 is created. Click Next to configure the new storage system (Figure 7).

Figure 7 Vfiler1 initial setup complete


5. Input the IP address of the administrative host and select the allowed
protocols. Then, click Next as shown in Figure 8.

Figure 8 Specify Administrative Information


6. Specify DNS configuration of vfiler1 and click Next as shown in Figure 9.

Figure 9 Specify DNS and NIS server information


7. Specify the IP address and Netmask and assign the Network Interface for
vfiler1 as shown in Figure 10.

Figure 10 Specify Network Configuration Information for vfiler1


8. At this point, the creation and configuration of vfiler1 is complete. Click Close
Window as shown in Figure 11.

Figure 11 Creation and configuration of vfiler1 complete


9. You next need to configure CIFS for Vfiler1. Check whether CIFS has been
enabled in FilerView Enable/Disable CIFS Services, as shown in Figure 12.

Figure 12 Enable/Disable CIFS Services


10.After you enable CIFS, go to the CIFS Setup Wizard. Choose the storage
system that you want to configure (in our case, vfiler1) and click Next as
shown in Figure 13.

Figure 13 Choose Vfiler to be configured

11.Input the Vfiler CIFS share name and click Next as shown in Figure 14.

Figure 14 Vfiler CIFS share name


12.Choose the network authentication type and click Next (Figure 15).

Figure 15 CIFS authentication


13.Input the CIFS Workgroup Name and click Next as shown in Figure 16.

Figure 16 CIFS Workgroup

14.Select the security style of the CIFS Vfiler share and click Next as shown in
Figure 17.

Figure 17 CIFS Security Style


15.Input the CIFS Root Password for vfiler1 and click Next as shown in
Figure 18.

Figure 18 Input CIFS Root Password

16.You are asked to commit the changes. Review the settings that you made and
click Commit. Click Back if you need to modify the settings. See Figure 19.

Figure 19 Commit the changes


Vfiler1 CIFS setup is now complete (Figure 20). You can access the Vfiler from
the network.

Figure 20 CIFS setup completed

MultiStore and flexible volumes
Data ONTAP features allow storage to be pooled (and managed as a pool) in a
data-centric (not disk-centric) approach without regard for physical disk locations
or configurations. Like the name implies, a flexible volume can be made flexibly
larger or smaller, independent of the underlying disk size. Additional flexible
volume features, such as instantaneous cloning, make flexible volumes a
quantum leap in storage manageability.

Flexible volumes are allocated out of a new constructed called an aggregate. An
aggregate is a collection of reliable RAID groups, which in turn consist of
individual disks.

MultiStore works with both flexible volumes and traditional volumes. All security,
storage consolidation, and SnapMirror-based migration and disaster recovery
functions are identical. The only exception is instantaneous SnapMover-based
migrations. SnapMover uses ownership of the underlying physical disks for the
migration, and because now a single disk can hold data for multiple flexible
volumes, it cannot be used to migrate a flexible volume. SnapMover can still be
used to migrate traditional volumes. Future versions of Data ONTAP will include
the ability to migrate aggregates using SnapMover technology.


Clustering considerations
Storage systems that are part of a cluster function independently during normal
operation. If one storage system undergoes a system failure or is shut down, the
partner storage system will continue to function as itself, while also accessing the
failed storage system's disks and assuming its identity. Each member of a cluster
must have a MultiStore license to take over its partner with a MultiStore license.

When using a cluster, up to 33 virtual storage systems can be created on each
node of a cluster, including the hosting storage system, known as vfiler0. Should
an outage occur on one of the clustered systems for any reason, virtual storage
systems restart automatically on the takeover storage system in a matter of
minutes. The virtual storage systems hosted by the storage systems of the
cluster are created and configured independently. That is, each storage system
can host a different number of virtual storage systems, and the Vfiler
configurations on the storage systems can be different from each other. In
takeover mode, the functioning storage system takes over all virtual storage
systems that are created on the failed storage system. These virtual storage
systems include the ones created as well as vfiler0. Therefore, for virtual storage
systems on the failed storage system to work correctly after the takeover, each
network interface used by a Vfiler in a cluster must have a partner interface
already defined.

When deploying System Storage N series clusters with virtual storage systems,
each storage system's IPspaces and partner network interfaces must be
configured correctly for the virtual storage systems to restart on the functioning
storage system after a takeover.

Transparent migration
MultiStore supports transparent migration. If the networking infrastructure is up to
the task, it is possible to migrate a Vfiler from one storage system to another
within seconds, with the higher-level protocols handling any requests
outstanding during the short migration time. The level of transparency depends
on the higher-level protocols.

MultiStore can eliminate disruption for NFS users during the migration process
without requiring any service interruptions, remounts, or system downtime. IP
SAN users using the iSCSI protocol can also migrate transparently between
storage systems. The only caveat is that Data ONTAP associates CHAP
authentication with the physical storage system. So, in an environment where
CHAP is used, the iSCSI connections need to be re-authenticated on the
destination storage system. There are plans to address this necessity to
re-authenticate in future versions of Data ONTAP.


Unlike NFS, CIFS is a state-full protocol, which means that the client and server
need to maintain an active TCP/IP connection during all times that a file is open.
Windows clients wait a finite time for a response to a CIFS request. After this
timeout, the redirector on the client assumes that the server is down and shuts
down the session. This timeout can be set on the client and defaults to the
maximum possible value of 45 seconds. If client session context is not
transferred within 45 seconds, it can result in data loss for clients that have CIFS
files open for writes, op-locks, and so forth. Thus, the Vfiler migration must
complete within the defined timeout period. While most Vfiler migration
handovers complete in less than 45 seconds, migration time depends on many
factors (including the networking infrastructure) and cannot be guaranteed.

Consolidating storage
For most companies, data storage growth combined with the rapid proliferation
of UNIX and Windows servers throughout the enterprise has complicated data
management. Data is spread among large numbers of disparate servers, each of
which must be managed and maintained.

MultiStore functionality adds even more flexibility to the already compelling
advantages offered by System Storage N series when used for data
consolidation. Companies with large numbers of UNIX and Windows servers
have long enjoyed the benefits of migrating data to a storage system, which
unifies shared access to UNIX and Windows data. Integrated cross-protocol file
locking for UNIX and Windows data, ease of use and management, scalability,
Snapshot™ technology, built-in RAID protection, and file system checksums are
all features intrinsic to System Storage N series. System Storage N series are
fast, simple, and reliable.

Using MultiStore, an administrator can connect to a storage system anywhere in
the world and create, set up, and deploy a Vfiler into production in a matter of
minutes.


Figure 21 shows a System Storage N series and two general-purpose UNIX or
Windows file servers. Imagine a scenario where the engineering data is
accessed primarily through NFS and the corporate data through CIFS. As time
passes and new applications are added, it becomes advantageous to access all
the data through both NFS and CIFS. Trying to patch and update the
general-purpose operating systems to serve both NFS and CIFS can be complex
and error-prone. In addition, the general-purpose servers can be redeployed for
a range of other applications if there was a more effective way to serve the files.
Licensing MultiStore on the existing storage system and creating a Vfiler to
replace each of the older general-purpose servers provides a cost effective
solution.

Figure 21 System Storage N series and two general servers acting as file servers


Figure 22 shows the System Storage N series hosting two virtual storage
systems that reuse the names of the older servers. The data previously stored on
the general-purpose servers has been copied to the new virtual storage systems,
and is now available through both CIFS and NFS. The general-purpose servers
have been redeployed elsewhere, providing investment protection and greater
return on investment.

Figure 22 Consolidated file server with a single N series using MultiStore

There are many benefits to consolidating data from a large number of
general-purpose servers to virtual storage systems running on a storage system.
The data can be centrally managed, backed up, easily scaled, and replicated to
other storage systems for disaster recovery purposes using proven SnapMirror
technology. In addition, powerful System Storage N series features such as
Snapshot, FlexVol™, and FlexVol Cloning become available to simplify
management and to empower the IT administrator.

In many cases, the consolidation is not readily apparent to users. As far as users
or applications are concerned, the file servers exist as they did before, using the
same names and IP addresses. Administrators do not need to change most
scripts or references to the servers or their network IP addresses within
applications. Administrators also do not need to modify records in the corporate
DNS namespace.


Migrating Vfiler
Through integration with either SnapMirror or SnapMover, virtual storage
systems can be migrated to other storage systems over a LAN, WAN, or
back-end storage interconnect for the purposes of load balancing or
maintenance. Integrated mirror relationships can be established to simplify the
migration of virtual storage systems to other physical storage systems.

Preparing for the migration or for disaster recovery procedures

Note: For complete information and worksheets designed to help guide the
configuration process, see the Data ONTAP MultiStore Management Guide.

Vfiler migration is motivated by a number of reasons. Migration might be
desirable for maintenance without interruptions, workload balancing for
performance, or as the only option in a disaster recovery scenario. Before the
administrator defines the Vfiler migration or the Vfiler disaster recovery
configuration, it is important to verify that each storage system to be used is
configured properly. Differences in the physical configuration of the destination
storage system, such as the number of network cards, can be taken into account
while establishing a migration or disaster recovery setup. However, some
configuration settings, such as the name of the storage system volumes, must
match in order for SnapMirror to function properly.


Figure 23 summarizes the steps to complete prior to defining a SnapMirror
migration or disaster recovery relationship.

Figure 23 Configuring MultiStore for disaster recovery and migration

Migrating Vfiler with SnapMirror
The process of establishing SnapMirror relationships for virtual storage systems
is automated by MultiStore to simplify administration and ensure accuracy. It is
still necessary to ensure that the source and destination storage systems are
licensed and appropriately configured, but the MultiStore software takes care of
the SnapMirror relationships.

When a SnapMirror relationship is established, a baseline transfer initializes the
mirror to create a replica of the Vfiler on the destination storage system. The
entire Vfiler—including its network and security settings, data, permissions, and
options—are mirrored as one. SnapMirror uses storage system Snapshots to
efficiently replicate incremental updates. Thus, SnapMirror is highly effective and
flexible while also efficient in its use of valuable bandwidth.


Each Vfiler's configuration, security, and networking information is stored within
its own “root” directory. This allows administrators to mirror or migrate complete
virtual storage systems over the network.

Migrating Vfiler with SnapMover
SnapMover is a no-copy data migration solution among storage systems that
share a common storage pool. These System Storage N series can be clustered
storage systems with access to all disks from both nodes, System Storage N
series gateways that can access the same LUNs over Fibre Channel, or a
SharedStorage™ pod with multiple storage systems connected to a common set
of back-end disks. SnapMover migration enables the administrator to move data
easily and quickly from a source node to a destination with no disruption to users.

Data migration is achieved by using standard SCSI-3 semantics to change the
ownership of the storage containers (LUNs or individual disk) in the storage pool.
The ownership information is updated very quickly and requires little actual I/O,
thus making the migration process extremely fast with minimal overhead. Data
migration is managed at the volume level (not individual disks/LUNs), making the
migration process simple and scalable.

The quick, no-copy migration opens the door to more options for managing
storage. It allow IT to easily migrate a data volume from an overloaded storage
system to another. Volumes can be quickly migrated from a storage system that
needs to be taken down for maintenance, and just as quickly returned back when
the storage system is back up. Users are not disrupted during the migration
process and continue to access data after migration in the same manner as
before. Because the migration is completed in seconds (not hours or days that
are typically required by a traditional data replication approach), the IT
organization can be much more responsive to its customers and cost effectively
provide higher levels of service.

MultiStore license is required on both the source and destination to enable the
data migration capability and to provide the transparent data movement benefit.

Disaster recovery using SnapMirror
Through integration with SnapMirror, the administrator can create and mirror
virtual storage systems automatically to other storage systems over a network for
disaster recovery. Integrated mirror relationships are established to automate the
creation and synchronization of a disaster recovery Vfiler. In a disaster recovery
scenario, the disaster recover Vfiler can be quickly activated at one of many
possible locations to restore services. After the disaster recovery Vfiler is online,
the mirrored Vfiler is an identical copy of its original source based on the last


successful SnapMirror update. The only difference between the original Vfiler
and the disaster recovery Vfiler is that the disaster recovery Vfiler is inactive until
a situation forces it to be activated. Thus, the failover can be transparent relative
to the applications and users throughout the enterprise.

Migrating a Vfiler versus creating a disaster recovery Vfiler
Although the migration Vfiler and disaster recovery Vfiler procedures have
much in common, they are designed for different purposes:
Migration Vfiler: Establishes a mirror and replicates the data. Upon
completion, the SnapMirror relationship is broken and the source Vfiler
destroyed. The source Vfiler volumes are not destroyed, so the Vfiler can be
quickly recreated at the original source if necessary.
Disaster recovery Vfiler: Establishes and maintains the mirror relationship
and keeps the (active) source and destination virtual storage systems
synchronized. The destination Vfiler remains dormant or inactive until which
time it must be activated. If access to the original (source) Vfiler is
re-established, the relationship can be effectively “reset” by repairing or
replacing the source storage system and re-synchronizing the data back to
the original source.

Both migrating and disaster recovery have a role in most enterprises, and
MultiStore permits both applications with the same license.

Scheduled replication for disaster recovery virtual storage systems
The interval in which SnapMirror updates occur should take into account the
amount of data and network speed between source and destinations. For
example, if the source and destination storage systems are connected through a
high speed LAN, the administrator can schedule mirror updates to occur at a
higher frequency than possible over a slower WAN. For more information about
configuration SnapMirror, see the Data ONTAP Data Protection Online Backup
and Recovery Guide.


Figure 24 illustrates disaster recovery with SnapMirror. In this illustration,
vfiler3.ibm.com is mirrored from storage1.ibm.com to storage2.ibm.com.
vfiler3.ibm.com can be activated on storage2.ibm.com if storage1.ibm.com
becomes unavailable. vfiler3.ibm.com appears in the network exactly as it did
before. Users, for example, would not necessarily know a Vfiler had been moved
to a different physical storage system.

Figure 24 Vfiler disaster recovery with SnapMirror


Enabling MultiStore functionality
There is no need to install any additional software to take advantage of the
MultiStore Vfiler functionality. MultiStore can be enabled by entering the correct
license code, as shown in Figure 25. The license provides instant access to the
Vfiler related commands, and the configuration process can being immediately.
For information about how to license MultiStore/Vfiler functionality, see the Data
ONTAP MultiStore Management Guide.

Figure 25 MultiStore license

When enabled, the hosting storage system becomes also known as vfiler0. The
name vfiler0 is used internally by MultiStore to identify the hosting storage
system. The hosting storage system's actual host name and configuration do not
change. Because of the security features of MultiStore, all networking and
storage resources need to be owned by one (and only one) Vfiler.


Be aware of the following key behaviors:
By default, vfiler0 owns all of the storage system's storage and networking
resources.
At any given time, any resources not explicitly assigned to a Vfiler belong to
the hosting storage system (vfiler0).
Each Vfiler must be assigned at least one storage resource and one
networking resource.
Moving, adding, or removing resources between virtual storage systems only
affects the associations between a vfiler and those resources. User data is
not affected.
When an administrator creates a Vfiler on a given volume or adds a volume to
an existing Vfiler, resources are moved from the hosting storage system
(vfiler0) to the new Vfiler.
When resources are removed from a Vfiler or a Vfiler itself is removed, the
resources associated with that Vfiler are returned to the hosting storage
system.

These behaviors help ensure that only authorized users and administrators have
access to resources and information in question.

Storage and networking resources
This section describes storage and networking resources.

Storage resources
Storage resources on storage systems start with a physical file system, or
volume. The volume can be either a Traditional Volume or a Flexible Volume.
Within a volume, special subdirectories can be created called qtrees that function
as logical volumes. Both volumes and qtrees can be assigned to virtual storage
systems as storage resources. Vfiler storage resources (volumes and qtrees)
can be added or removed at any time. Removing the storage resource holding
the Vfiler configuration information is not allowed without first destroying the
Vfiler in question.

The storage system's entire root volume (typically vol0) cannot be assigned to a
Vfiler, though qtrees created within the root volume can be assigned to a Vfiler.
All storage resources assigned to virtual storage systems are secured within the
file system. If a Vfiler is deleted, for example, the portion of the file system and
data previously owned by that Vfiler might not be accessible to other virtual
storage systems in different security domains.


Volumes or qtrees assigned to virtual storage systems are known as storage
units. The first assignment of a volume or qtree to a Vfiler is known as the
primary storage unit. The primary storage unit contains an /etc directory that
consists of a subset of the files normally found in the hosting storage system's
/etc directory, specific to that Vfiler's configuration. Examples of this information
are UNIX NIS or Windows domain information, configuration options, disk quota
assignments, UNIX/Windows user mappings, DNS namespace and server
information, and so forth.

As a result, each Vfiler independently stores information about its membership in
Windows or UNIX security domains. One Vfiler can serve UNIX clients only,
another can be a member of a Windows 2000 or Windows .NET Active Directory
Domain, a Windows NT® 4.0 and NIS Domain, and so forth.

Resources assigned to a Vfiler are owned only by that Vfiler. In other words,
each Vfiler and its resources are distinct and meaningful only to itself and the
security environment (for example, Windows Domain) to which it belongs. The
hosting storage system administrator or an administrator responsible for vfilerA
does not necessarily have any access to resources assigned to vfilerB.

Networking resources
There are many choices available when it comes to choosing network cards for a
storage system. However, the storage system's physical network cards
(interfaces) can also be logically configured in combinations of up to 128 virtual
interfaces, each of which is indistinguishable from a physical interface when it
comes to assigning IP addresses. Virtual storage systems can be created and
assigned IP addresses that correspond to any network interface (logical or
physical) on the storage system.

Each physical interface can be used individually, and assigned a base IP
address.The storage system's physical interfaces can be combined into virtual
interfaces or VIFs, which are link aggregations or trunks of (up to 16) combined
links providing fault tolerance and improved throughput. Multiple (logical) Virtual
Local Area Network (VLAN) interfaces can be created and associated with any
physical interface or VIF.

In addition to the flexibility offered by VLANs and VIFs, IP address aliases can be
assigned to any interface. IP address aliasing allows more than one IP address
at a time to be associated with an interface.


IPspaces
Virtual storage systems can be grouped into IPspaces, each of which represents
a distinct networking environment. An IPspace defines an IP address space that
is separate from other IPspaces. Each IPspace maintains its own distinct routing
table and no cross-IPspace traffic is routed. In addition to the always present
default-ipspace, up to 100 separate IPspaces can be created on a storage
system.

IPspaces are beneficial in environments where a storage system must host
storage for two separate departments or organizations, each with private
networks. They are invaluable to service providers who can readily create and
allocate a brand new virtual storage system with its own secure storage, secure
administration, and secure routing to customers. Virtual storage systems allow
service providers to deploy and bill for service within minutes.

IP addresses defined within an IPspace are only meaningful within that IPspace.
That means that IP addresses are not forced to be unique across IPspaces, and
the same IP address can be used in multiple IPspaces for more standardized
management. Virtual storage systems in different IPspaces cannot internally
communicate with each other, even though they are running on the same hosting
storage system. Incoming network traffic on the storage system's network
interfaces is internally tagged with the IPspace ID to identify the target Vfiler, and
virtual storage systems use the routing table for their IPspace when
communicating with other computers.

By default, a single default IPspace exists, named default-ipspace. All of the
storage system's interfaces belong to the default-ipspace unless they are
assigned to a non-default IPspace created by the administrator.

Before an IPspace can be used, it must be assigned a network interface. Any of
the storage system's physical, VLAN, or VIF network interfaces can be assigned
to an IPspace. By creating and using logical VLAN interfaces, more IPspaces
can be created than physical interfaces available in the storage system.

Note how each Vfiler has the same IP address. This is possible because each
Vfiler is in a different IPspace, each of which functions as though on a separate
LAN. They function within a network space that has its own network addressing
and routing table. Thus, even though they have the same IP address and are
hosted on the same storage system, there are no address conflicts because they
cannot communicate with one another unless they go through an external
network router. This kind of practice can simplify planning and administration
because all “customers” have similar configurations, with servers which have the
same role using the same IP address across customers. See Figure 26 for
graphical illustration.


Figure 26 Simplified management and security using IPspaces

Using VLANs with IPspaces
Ethernet switches learn about the networks connected to them by analyzing the
source address of incoming frames. The network addresses and ports on which
they were discovered are stored in tables and used as the basis for traffic
forwarding. When a switch receives a network frame on one of its ports, it
analyzes the frame to see if the destination matches any of the destinations
known on its other ports. If a match is found, the frame is forwarded or switched
to that port only. If no match is found, the frame is forwarded to all ports.

Unicast frames contain a destination address, while frames with no destination
address, such as broadcasts (to all hosts), do not. By default, switches still
forward broadcast (and multicast) frames to all ports. Therefore, the mixture and
volume of network traffic can still have a profound effect on network performance
and reliability.

VLANs can be defined on network switches that confine intra-segment traffic and
broadcasts only to VLAN members. Many modern network switches support the
creation of port-based or protocol-based VLANs. Port-based VLANs are defined
by designating specific ports on a switch as members of a VLAN. Protocol-based
VLANs limit traffic to VLAN members according to certain protocol criteria,
regardless to which ports they are connected.

Data ONTAP supports the creation of logical VLAN interfaces that support VLAN
tagging. A VLAN tag is a unique identifier that indicates the VLAN to which a
frame belongs. VLAN interfaces are assigned IP addresses like any other
interfaces in the storage system.


When an IPspace is associated with a VLAN interface, virtual storage systems
within that IPspace only communicate with other computers that are members of
the same VLAN.

In Figure 27, the storage system has two Gigabit Ethernet network interfaces (e7
and e8) that are combined into a storage system VIF (trunk) for maximum
performance and reliability. Four VLAN interfaces are defined on the storage
system's tr1 VIF interface that correspond to the VLANs defined on a network
switch. There are four IPspaces (tr1-10, tr1-20, tr1-30, and tr1-40), each of which
are assigned to one of the four VLAN interfaces. There is one Vfiler in each
IPspace whose IP addresses are associated with each IPspace/VLAN.

The result is that each Vfiler functions as thought it is on its own local area
network. It should be noted that each one of the virtual storage systems in the
example could also be members of different security domains. This secure
architecture allows for maximum flexibility and allows the storage system to
determine the target VLAN, IPspace, and Vfiler.

Figure 27 Using Virtual Interfaces, VLANs, and IPspaces with a single network switch


Higher-level integration
The IBM System Storage N series integrates with several common data
management tools. This section discusses some of these tools.

Virus scanning
Data ONTAP includes integrated antivirus server support for data accessed by
Windows computers. The efficient, on-access nature of the N series storage
system antivirus architecture ensures files are scanned before allowing any
reads, writes, or changes to data.

For the virus scanning server or servers to intercept file I/O requests, antivirus
servers must register with the hosting storage system or Vfiler. Virus scanning
can be enabled or disabled for each Vfiler, and options can be set independently
for each Vfiler.

Virtual storage systems can use scanning servers that are either:
Registered with the hosting storage system
Registered with a specific Vfiler

Quota management
Administrators can manage disk quotas on a per-Vfiler basis on the qtrees and
volumes owned by a particular Vfiler. However, if a qtree owned by a Vfiler
resides in a volume owned by the hosting storage system, the hosting storage
system administrator can also specify a quota for the qtree. The qtree cannot
exceed the storage system specified limit in the more restrictive of the two
quotas (the lesser quota takes precedence.) Quota settings are preserved when
virtual storage systems are duplicated through SnapMirror to other hosting
storage systems. For a complete list and description of Vfiler-related commands,
see the Data ONTAP MultiStore Management Guide.


Windows administration
When all of the necessary setup steps are complete, the Vfiler shows up in the
network just like a regular storage system. For example, Figure 28 shows how
RED1 hosting storage system and its two virtual storage systems BLUEN1 and
BLUEN1 appear like native active directory servers within the Active Directory
Users and Computers administrative window.

Figure 28 Windows Active Directory sees Vfiler like any other storage system

Some aspects of storage system or Vfiler management can be performed by
right-clicking on the storage system and selecting the Manage menu option, as
shown in Figure 29.

Figure 29 Vfiler Management from Active Directory


Figure 30 shows the detailed Vfiler management in Active Directory showing
user sessions connected to BLUEN2 vfiler.

Figure 30 Vfiler Management window

Summary
MultiStore allows a storage system's storage and networking resources to be
partitioned into multiple virtual storage systems, each of which appears as an
individual storage system in the network. The dynamic, flexible nature of virtual
storage systems simplifies UNIX and Windows storage consolidation, and offers
unified access to data over both CIFS and NFS.

Virtual storage systems can be wholly mirrored to other storage systems over a
network for data migration, disaster recovery, or load balancing purposes. Virtual
storage systems can be grouped into private network address spaces and
belong to different security domains for maximum security.

MultiStore simplifies data storage and management for companies or service
providers requiring highly available storage and secure, multi-domain flexibility.


The following capabilities lead directly to added value for organizations using
MultiStore and SnapMover:
Different organizations might be responsible for managing the hosting
storage system or each Vfiler. Organizations benefit by centralizing
management of the hosting storage system, while allowing client departments
to independently, securely, and responsively manage their own data. The
result is efficiency and great service, with the some functions reliably
centralized and scaled, while others are distributed closer to the user who
ultimately benefits from responsive and more tailored service.
Vfiler administrators for different organizations do not have permission to
access other virtual storage systems unless explicitly allowed. This allows for
more flexible management policies and greater security.
Virtual storage systems can be managed using the CLI, the Web-based
FilerView application, the centralized DataFabric® Manager, or the Manage
ONTAP API. Many management options means it is possible to integrate
storage systems and MultiStore into a wide range of existing operations and
processes. The result is rapid deployment and reduced process
re-engineering costs.
Virtual storage systems can be created and destroyed easily as needed to
accommodate temporary projects or changing project priorities. No additional
hardware needs to be deployed or managed. The unprecedented ease and
speed opens doors to more efficient operations and project opportunities.
As business needs and workloads change, administrators can migrate virtual
storage systems to ensure that critical projects receive the required level of
service and response times, while retired projects are still available online
through lower-tier storage. As priorities change, the administrator simply
adjusts Vfiler deployments. This flexibility leads to greater ROI and lower
TCO.
Storage management is virtualized, allowing the IT architect to separate
many of the logical needs of the infrastructure from the physical hardware
used to build it. Because less hardware is required, management and
acquisition costs can be reduced, and adaptability improved.
In conjunction with SnapMover technology, administrators can migrate a
Vfiler to another storage system in seconds, with no data being copied and no
interruptions to the user. Combined with Grid technology, the load balancing
capabilities provide opportunities for unprecedented application scaling
efficiencies.
MultiStore and SnapMover technologies can also be used with Vfiler
migration for system maintenance with no operational interruptions.
Non-disruptive maintenance delivers higher levels of service and allows more


profitable operations by being able to offer more stringent Service Level
Agreements.
SnapMirror can be used to replicate virtual storage systems to one or more
target storage systems, where the mirrored virtual storage systems can be
quickly activated for disaster recovery purposes. This significantly simplifies
disaster preparedness, and reduces the chances of anything else going
wrong in the stressful minutes following a disaster.

The team that wrote this IBM Redpaper
This IBM Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization (ITSO), Tucson,
Arizona.

Alex Osuna is a Project Leader with the San Jose ITSO. He has over 27 years in
the IT industry and 22 years of experience in the hardware and software storage
area dealing with maintenance, development, earlyship programs, education,
publishing, performance analysis, and technical sales support. He holds 10
certifications from IBM, Microsoft, and Red Hat.

Chrisanthy Carlane is an IT Specialist with IBM Information Technology
Services in Indonesia. She has five years experience providing enterprise-wide
infrastructure implementations, migration, and support on IBM Tape and Storage
System and System x™ servers. She has certifications with IBM, Cisco,
Microsoft, Red Hat, and McDATA and holds Bachelor of Economics - Accounting
from Tarumanagara University, Jakarta, Indonesia.

Thanks to the following people for their contributions to this project:
Chad Mitchell, IBM Systems and Technology Group, Development
Thorsten Busch, IBM ATS Customer Solutions Mainz, IBM Deutschland
GmbH
Miroslav Klivansky, Network Appliance™ Corporation
John Philips, Network Appliance Corporation


Notices

This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. 41

This document created or updated on August 22, 2007.
Send us your comments in one of the following ways: ®
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an email to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ® Redbooks® System Storage™
IBM® System x™

The following terms are trademarks of other companies:
Vfiler, Snapshot, SharedStorage, FlexVol, Network Appliance, SnapMover, SnapMirror, MultiStore,
FilerView, DataFabric, Data ONTAP, and the Network Appliance logo are trademarks or registered
trademarks of Network Appliance, Inc. in the U.S. and other countries.
Vfiler, Snapshot, SharedStorage, Data ONTAP, Network Appliance, SnapMover, SnapMirror, MultiStore,
FilerView, DataFabric, and NetApp logo are trademarks or registered trademarks of NetApp Corporation or
its subsidiaries in the United States, other countries, or both.
Vfiler, Snapshot, Data ONTAP, SnapMover, SnapMirror, MultiStore, FilerView, DataFabric, Network
Appliance, The Network Appliance logo, the bolt design,Camera-to-Viewer, Center-to-Edge,
ContentDirector, ContentFabric, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW
NetApp on the Web, RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN,The
evolution of storage, Virtual File Manager, and Web Filer are trademarks of Network Appliance, Inc. in the
U.S. and other countries. All other brands or products are trademarks or registered trademarks of their
respective holders and should be treated as such.
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Active Directory, Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.


Ibm system storage n series with multi store and snapmover redp4170

More Related Content

What's hot (18)

Similar to Ibm system storage n series with multi store and snapmover redp4170 (20)

More from Banking at Ho Chi Minh city (20)

Recently uploaded (20)

Ibm system storage n series with multi store and snapmover redp4170