iStorage Server supports iSCSI SAN on Itanium Server


KernSafe iStorage Server as first software fully supports Itanium architecture for creating iSCSI SAN Targets.

The Itanium architecture is based on explicit instruction-level parallelism, in which decisions about which instructions to execute in parallel must be made by the compiler. This contrasts with other superscalar architectures which depend upon processor functionality that keeps track of instruction dependencies at runtime. Itanium cores up to and including Tukwila execute up to six instructions per clock cycle.

Main benefits of Itanium architecture are:

• Multi-OS support
• Lower overall Cost of Ownership for enterprise IT
• ·Assurance of leading performance and scalability over the long-term
• Greater memory addressability
• More complex applications and computing environments
• Secure web server transactions
• Computer aided design such as Mechanical Analysis
• Very large memory databases
• Industry-standard servers in every tier of the data center

KernSafe iStorage Server is an advanced and powerful, full-featured iSCSI Target software that makes any x86, x64 or even Itanium Windows machine into an iSCSI Target.

iStorage Server is an IP SAN solution that allows you quickly export existing storages such disk images, physical disks, partitions, CD/DVD-ROMs, tapes or any other type of SCSI based devices and even a variety of popular CD/DVD images to its client machines, which delivers immediate benefits allowing storage to be consolidated, virtualized and centrally managed. iStorage Server also provides RAID-1 (mirror) feature, which allows you create two devices for mirror backup, the mirror devices can be local image files or remote iSCSI devices. iStorage Server has been added support for Microsoft Virtual Disk File (VHD) and VHD snapshots at the recent release. So it is an ideal choice for any sized business.

You can download Itanium native Trial version of iStorage Server here.

iStorage Server supports creation of Failover Clustering

Cluster Shared Volumes (CSV) is a feature of Failover Clustering available in Windows Server 2008 R2 for use with the Hyper-V role. A Cluster Shared Volume is a standard Cluster disk containing an NTFS volume that is made accessible for read and write operations by all nodes within the cluster. This gives the virtual machine (VM) complete mobility throughout the cluster as any node can be an owner, and changing owners is easy. In Windows Server 2008, the VM and all dependent LUN resources form a dependent group that can only be moved or failed over as a complete unit. This means that if additional VMs created dependencies on these same LUNs they become members of that same group and cannot be independently moved. Move one VM or LUN and you end up moving all of the VMs and LUNs in the group. Additionally, this model created storage management challenges where hundreds of VMs would require hundreds of LUNs. This all changes in Windows 2008 R2 with CSV. Now, the VMs with VHDs deployed on a single CSV have no dependency on the disk resource and can be freely moved to or from any node in the cluster.

To understand how Cluster Shared Volumes (CSV) works in a failover cluster, it is helpful to review how a cluster works without CSV. Without CSV, a failover cluster allows a given disk (LUN) to be accessed by only one node at a time. Given this constraint, each Hyper-V virtual machine in the failover cluster requires its own set of LUNs in order to be migrated or fail over independently of other virtual machines. In this type of deployment, the number of LUNs must increase with the addition of each virtual machine, which makes management of LUNs and clustered virtual machines more complex.

Cluster Shared Volumes provides the following benefits in a failover cluster:

• The configuration of clustered virtual machines is much simpler than before.
•  You can reduce the number of LUNs (disks) required for your virtual machines, instead of having to manage one LUN per virtual machine, which was previously the recommended configuration (because the LUN was the unit of failover). Many virtual machines can use a single LUN and can fail over without causing the other virtual machines on the same LUN to also fail over.
• You can make better use of disk space, because you do not need to place each Virtual Hard Disk (VHD) file on a separate disk with extra free space set aside just for that VHD file. Instead, the free space on a Cluster Shared Volume can be used by any VHD file on that volume.
•  You can more easily track the paths to VHD files and other files used by virtual machines. You can specify the path names, instead of identifying disks by drive letters (limited to the number of letters in the alphabet) or identifiers called GUIDs (which are hard to use and remember). With Cluster Shared Volumes, the path appears to be on the system drive of the node, under the \ClusterStorage folder. However, this path is the same when viewed from any node in the cluster.
• If you use a few Cluster Shared Volumes to create a configuration that supports many clustered virtual machines, you can perform validation more quickly than you could with a configuration that uses many LUNs to support many clustered virtual machines. With fewer LUNs, validation runs more quickly. (You perform validation by running the Validate a Configuration Wizard in the snap-in for failover clusters.)
• There are no special hardware requirements beyond what is already required for storage in a failover cluster (although Cluster Shared Volumes require NTFS).
• Resiliency is increased, because the cluster can respond correctly even if connectivity between one node and the SAN is interrupted, or part of a network is down. The cluster will re-route the Cluster Shared Volumes communication through an intact part of the SAN or network.

On more information on how to deploy CSV in Windows Server 2008 R2, please refer to this site http://blogs.msdn.com/b/clustering/archive/2009/02/19/9433146.aspx

You can download Trial version of iStorage Server here.

iStorage Server supports Internet Protocol Security (IP SEC) architecture

Internet Protocol Security (IPSec) is an architecture defined by the Internet Engineering Task Force (IETF) RFC 2401. This architecture involves several protocols that perform various functions in the architecture.

A network is not secure until servers can identify the computers communicating with them. IPSec enables secure, trusted communications between IP addresses. The system behind the IP address has an identity that is verified by using an authentication process. The only computers that must be aware of IPSec are the sending and receiving computers. Each computer handles security at its respective end, and assumes that the medium over which the communication takes place is not secure. Any computers that route data between the source and destination computer are not required supporting IPSec.

Main benefits of IPSec are:

• Strong security that can be applied to all traffic crossing the perimeter
• Transparent to applications
• No need to change software on a user or server system
• There is no need to train users on security mechanism
• Secure remote access over the Internet

If you want to learn more about iStorage Server support for IP SEC under Windows operating system, please refer to this White Paper

You can download Trial version of iStorage Server here.