P4000 存储虚拟化及存储整合行业应用.pptVIP

* Remote Copies are based on snapshots. A Remote Copy is essentially a snapshot that is copied to a remote cluster. Because they’re based on snapshots, they also take advantage of thin provisioning and do not require reserve space. If you have a primary site with volumes and snapshots and a second DR site, you can copy the volume and snaps to the remote site via your WAN link Remote copies can be scheduled based on your DR needs. The initial data copy copies the entire volume – Each additional remote copy sends only the changed data to the remote site. Remote Copies can be run over most any WAN link, and can take advantage of WAN encryption (VPN) and/or compression (Riverbed) Bandwidth can be managed through the CMC by editing the management group properties. Like snapshots, no space needs to be reserved ahead of time on the remote cluster You can mount these remote copies as fully readable and writable volumes, so that if the primary site goes down, you simply attach the remote copy to a host and continue A wizard guides you through both the failover and failback scenarios * * This is an example that shows how our clustered scalability benefits a virtualized environment: The example starts with a 3-node cluster which is supporting 30 VMs (as well as SQL and Exchange). Doing rough calculations, this configuration delivers around 180 random small block IOPS per VM. This is what we call “spindle limited”; the bottleneck is the number of drives in your SAN all running at max capacity for this kind of IO. You may run into two issues: you may determine that this number IOPS is insufficient for the applications being run and want to increase the overall IO capacity of the SAN, OR you may be adding more virtual machines and therefore require more IOPS, or a combination of both. (NOTE: Other performance bottlenecks may exist besides storage. SAN/iQ 8 will tell you if in fact the SAN is the performance bottleneck by looking at the performance monitor). Adding ad