| | Details |
| Vendor | DataCore Software Corporation |
| Product Type | Storage Virtualization Software |
| Market Space | Enterprise |
| Product | SANsymphony™ Storage Virtualization Software |
| Description | DataCore eliminates storage-related disruptions, bottlenecks and funding roadblocks that jeopardize server and desktop virtualization projects, letting you protect, provision, share, reconfigure, migrate, replicate, expand and upgrade storage without slowdowns or downtime. It contains costs, mitigates risks, and improves I/O performance. |
| Announced | 2000 |
| Current version / Release date | Release 7.0, 2009 |
| Updates | Available for download for customers under annual maintenance contract |
| Packaging | Supplied as a downloadable CD image with context sensitive Help files |
| Licensed By | Disk capacity under management, per node, some optional features |
| Warranty | 1 year against software defects |
| SUPPORTED ENVIRONMENTS | |
| Main Features | virtual disk pooling, synchronous mirroring, high-speed caching, asynchronous remote replication, thin provisioning, online snapshots, non-disruptive disk migration and continuous data protection (CDP) |
| Host Connectivty | Fibre Channel, iSCSI, Fibre Channel over Ethernet (FCoE) |
| Access Type | Block disk I/O over a physical or virtual SAN |
| Host Environments Supported | Computer systems running standard Windows operating systems including (Windows Server 2000, 2003, 2008, Hyper-V, Windows XP, Windows 7)
UNIX, HP-UX, Sun Solaris, IBM AIX, RedHat Linus, Suse Linux, Apple MacOs, VMware ESX / vSphere, Citrix XenServer, |
| Disks Supported (back-end) | Any internal drives, external drives, external disk arrays, JBODs, Solid State Disks (SSD), and intelligent storage system supported on Windows Server 2008 may be attached to the DataCore node(s). They may be direct-attached or SAN-connected. |
| Disk Interfaces Supported (back-end) | Any disk interfaces supported by Windows Server 2008 including SAS, SATA, USB, FireWire, iSCSI, Fibre Channel. |
| SAN Switches Supported | All standard iSCSI and Fibre Channel switches are supported |
| Network Interfaces | Standard IP network interfaces for internode communications, console access, and asynchronous remote replication between nodes. |
| PLATFORM | |
| Operating Platform | SANsymphony is installed on standard Windows Server 2008 platforms, which then become a high-performance Storage Virtualization node |
| Operating System Requirements | Windows Server 2008, R2 |
| Processor | Standard Intel/AMD x86/X64 CPUs |
| Memory Required (min) | 1 GB RAM. |
| Disk Cache | Up to 1 TB of processor memory (RAM) per node may be used as disk cache |
| Disk Capacity | Several hundred TBs per node |
| Max Nodes in a group (region) | >>8 |
| PERFORMANCE | |
| IOPS/ node | Dependent on configuration of underlying hardware platform. |
| Bandwidth/node | Dependent on configuration of underlying hardware platform. |
| Max # of Virtual Volumes | There could be limitation on number of Virtual Volumes created on each SANsymphony node, but the limitation will be defined by size of each Virtual Volume and performance requirements per SANsymphony Node. But, since SANsymphony is on N+1 Grid Architecture, you may scale out the number of SANsymphony Nodes to eliminate any nodal limitations on number of Virtual Volumes, performance, number of ports and ... |
| Min size (GB) of virtual volume | 0.001 GB |
| Max size (GB) of virtual volume | 1 Petabyte = 1024 TBs |
| Ability to throttle migration of virtual volume | SANsymphony software possesses revolutionary Quality of Service (QoS) features for prioritizing workloads and reporting storage usage, which makes it feasible to deploy a centrally managed storage infrastructure across the enterprise while reserving adequate bandwidth for the most demanding needs. Essentially, virtual storage resources associated with applications are categorized into separate groups known as storage domains. Relative priorities (high, medium and low) are assigned to each. SANsymphony software enforces the dynamic allocation of network storage bandwidth accordingly. |
| Max # of Physical Volumes | The max number of Physical Volumes is dependent on the Storage Sub-System Hardware |
| Physical Volumes (max size) | 1 Petabyte |
| Host Initiators (max #) | Because of SANsymphony N+1 Grid Architecture, a single SANsymphony node could contain multiple (depending on number of slots on the motherboard) multi-port FC HBAs or iSCSI NICs that would be assigned to a number of hosts. That would be the only limitation within a single node. But since there could be multiple of these SANsymphony nodes working on a N+1 network, there is no real fixed max number of hosts that a SANsymphony configuration could support. |
Snapshots
Incremental & Full clones | SANsymphony supports Instant Point-in-Time Snapshots along with Full Copy clones (known as complete images. You may periodically update snapshots to a later point in time with just the changed blocks that transpired after the last snapshot. You may also use snapshots to restore the source volume via the Source Update option. Snapshots are readable and writeable. SANsymphony uses copy-on-first-write technology as well as thin provisioning to significantly reduce the space taken up by incremental snapshots. The snapshot is available immediately upon request. |
| RAID Levels | SANsymphony supports software mirroring and striping across physical disks behind each DataCore node. It can also offload RAID protection to back-end RAID subsystems. |
| Synchronous replication (Inter-node Mirroring) | SANsymphony synchronously mirrors virtual volume in lock step across two DataCore nodes. Separations up to 35 kilometers are typically achieved using dedicated high-bandwidth optical routes across Metropolitan Area Networks (MANs). Longer distances may be achieved for more latency-tolerant use cases. |
| Asynchronous Remote Replication | SANsymphony supports Asynchronous Remote Replication over conventional LANs and WANs using standard TCP/IP protocols. Secure, encrypted connections such as VPNs and trunked or aggregated multi-link circuits can be used to enhance the privacy and speed of inter-site transmissions. |
| Multi-pathing Support (Linux) | SANsymphony supports Multi path drivers for different Linux versions and different OS types. |
| Multi-pathing Support (Windows) | Supported. DataCore MPIO supports Auto failover and Auto Failback between primary and alternate path. It also support failover and failback between FC and iSCSI inside a single server. |
| Multi-pathing Support (Solaris) | Supported. SANsymphony has DataCore Alternate Path drivers for different versions of Solaris. Also, SANsymphony supports few third party AP drivers for Solaris. |
| Multi-pathing Support (VMware) | Supported. SANsymphony supports different versions of Vmware ESX. |
| Max # of SAN Ports Consumed | That depends on number of SANsymphony Nodes within the SAN island. |
| Fabric Zoning considerations | SANsymphony requires two fabric zones, Storage Zone and Client Zone. If there are different switches are used for storage and client, then there are no zoning required on any of the switches. |
| Zones Per Host | Since DataCore does not use LUN Masking technique, all hosts could co-exist in a single zone. But as a best practice policy, DataCore recommends creating a zone for every type of OS to separate Windows servers from Linux and.... |
| High Availability Configuration | No single point of failure N+1 scalable grid architecture If a back-end channel fails then all LUN I/O activity will continue on the remaining healthy back-end channel/channels. This same feature is used to distribute and balance Synchronous Mirror LUNS over multiple Internode channel paths. If an Internode channel path fails (failed HBA) network synchronous mirrors will continue to remain in synch.
Thin provisioning (Virtual Capacity) pools have also been extended with a new RAID 1 internal mirroring pool-by-pool, physical disk-by-physical disk feature. This feature increases pool resource availability in case of a physical disk failure . Thin provisioned pool accessibility and availability can also be ensured by setting up hot spare volumes so that if an actual pool failure occurs new volumes are automatically activated and data is re-synched with it’s high availability partner volume. All of this occurs transparently to the user applications using these high availability volumes.
Also with Version 6.0, in case of a storage domain server failure or a planned maintenance activity high availability network synchronous mirror recoveries can be prioritized so that high priority virtual volume resources are the first to get back into synch after the failure event or maintenance activity is completed.
Finally, DataCore’s Windows Multipath (MPIO) driver has also been advanced and includes a preferred path auto failover / failback feature. DataCore MPIO supports FC, iSCSI or a mix of both types. Preferred paths are easily setup, balanced and controlled using SANsymphony’s Administration GUI. This enables I/O loads to be controlled and balanced by the storage administrator. |
| Load Balancing | Explicit load balancing is achieved by spreading virtual volumes assignments across multiple ports. Multiple back-end channels to LUNs within a device are supported. If one back-end channel fails then all LUN I/O activity will continue on the remaining healthy back-end channel/channels. |
| Non-disruptive upgrades | Yes. Non-stop data accessibility is configurable with “N+1” redundant SDS nodes that circumvent any single point of failure. Such innovative and cost-sensitive architecture ensures that service level obligations continue to be met in spite of component failures. Essentially, the I/O responsibilities associated with an outage, scheduled or unexpected, are distributed in real-time among the remaining storage resources being managed by SANsymphony. Clients automatically exploit alternate paths to other running SANsymphony Server’s to maintain end-to-end high availability |
| Online Infrastructure Expansion | Yes. SANsymphony could expand the configuration on line with out any down time. If more throughput or IO is required, SANsymphony node(s) could be added without taking down any host. Also, when using NMV volumes (Thin Provisioning), if more storage is needed, you can increase the pool size, without effecting any host or any Virtual Volume presented to those hosts. |
| LUN Security / Masking | SANsymphony does not use LUN Masking technology. All FC or iSCSI ports connected to a node are discovered automatically. Once an FC port WWN or iSCSI IQN are discovered, the SANsymphony will serve up a Virtual Volume to that port. Hosts may only access virtual volumes specifically assigned to them over specific ports |
| Virtual / Physical Correlation (Troubleshooting) | Within SANsymphony each Virtual Volume could be created from multiple physical resources (storage). SANsymphony provides detailed information about the which physical pool the Virtual Volume is created from and which ports are used to present the Virtual Volumes to the hosts. |
|
|
| | Thin Provisioning Virtual Capacity (NMV) Extensions – Disk Pooling
DataCore introduced thin provisioned Virtual Capacity Network Managed Volumes (NMV’s) with SANsymphony 5.0. It’s a proven technology that almost every customer utilizes and enjoys. It takes the guess work out of how much disk space to allocate to an application. Configure up to 1 PB volumes and SANsymphony takes care of allocating actual disk space as the demand for physical space increases from the running application. New features have been added to enhance the use of thin provisioned Virtual Capacity volumes. Two new pool types have been introduced (fixed size Striped pools and fixed size Spanned pools). All pools are easily configurable using SANsymphony’s administrative GUI. In addition, thin provisioned pools can be physically configured with disks that are internally mirrored so that data is transparently duplicated onto another physical disk in the pool. This can be applied to all disks in the pool or any subset. This feature provides another layer of availability and more importantly allows for the easy migration of data from one disk type to another. Once the data is in synch the source disk can be broken off and removed from the pool and re-purposed for some other use in the system. |
| High-speed Caching | I/O Performance: SANsymphony converts the memory inside each server that it has been installed on (Storage Virtualization Server) to a storage Cache. Advanced caching techniques inherent in SANsymphony’s design accelerate the response time of concurrent reads and writes from multiple application servers to virtual disks on the storage area network. The performance enhancements come inexpensively, exploiting the low-cost memory of the commercial processor platforms on which SANsymphony runs. SANsymphony’s cache is closely analogous to that found in modern hi-end storage subsystems.
It resides between the operating system on the application server and the physical storage. Like cache found on storage subsystems it provides a variety of caching services noted below:
• Read-ahead: When a request for a block is satisfied, SANsymphony will automatically pre-fetch adjacent blocks into its cache on the principal that if “block X” is required, “blocks X+1 and X+2” will probably be requested shortly afterwards.
• Write-behind: Unless specifically told not to cache writes, ANsymphony will respond with “I/O complete” when a request is cached. It will then flush the cached request to disk when convenient.
• Write-coalescing: One of the reasons that writes are not normally flushed immediately to the disk is to allow SANsymphony to better organize the sequence of writes and to concatenate writes from adjacent blocks into a single operation.
While monolithic storage controllers only cache physical disks internal to their cabinets,
SANsymphony’s caching acceleration applies to all multi-vendor storage devices configured
throughout a Storage Area Network. The caching strategies implemented by SANsymphony have been thoroughly tested and proven effective on generation after generation of hardware based storage controllers. |