HyperIP by NetEx Blog

2016 NetExIP-HyperIP Security Enhancement Update

Posted by Marketing

NetEx/IP® and HyperIP® Today

Network Executive Software, Inc. (NESi) brings high performance file transfer technology to the industry-standard IP environment with its NetEx/IP and HyperIP software products.

NetEx/IP is many times faster than TCP over long distances, which makes it the ideal solution for moving massive amounts of mission- or time-critical data across the country or across the globe.  As proven by our long-term users, NetEx/IP has the highest throughput rates over long distances with no degradation of performance because of its efficient bandwidth utilization and mitigation of the effects of packet loss and latency. In fact, NetEx/IP and its predecessor product NetEx/HC (HyperChannel) have provided solutions for moving data for global corporations and US state and government agencies for more than 30 years.

For existing TCP applications, the premier solution is NESi’s low cost HyperIP.  HyperIP transparently implements NetEx/IP in the data path to provide all the NetEx/IP improvements, plus compression of data, on a virtual machine without having to modify existing applications or operating procedures.

The Challenge: Securing the Data

With an increase in hacking and breaches of sensitive databases in recent years, many corporations (especially those in the financial, government, or health sectors) and US government agencies are looking at ways to better protect data transiting between sites and the databases themselves.  Data security is also of utmost importance for those customers utilizing shared/public networks.

NetEx/IP Security Enhancements

NESi recognizes this concern for data protection and is therefore planning to enhance NetEx/IP and HyperIP over the next year with standards-based security technology like Transport Layer Security (TLS) to significantly increase the security of the data being moved across the computer room, the country, or globally.

TLS is a cryptographic protocol that secures data as it is transmitted, focusing on authentication, data integrity, and data confidentiality. With TLS, keys are generated uniquely for each connection and are based on a shared secret negotiated at the start of a session, providing security between two applications using NetEx/IP or HyperIP.  Adding TLS to our NetEx/IP products will also provide improved security for our BFX & PFX utilities, which interface upward to customer applications.

In addition to data security, adaptive block compression of data will also be added to NetEx/IP, thus decreasing WAN bandwidth usage and effectively increasing the application data throughput over the network.

This entry was posted in Hyper IP, HyperIP, Netex, and tagged , , , , , , , , Bookmark the permalink.

Solving WAN Challenges of Workload Mobility Using HyperIP

Posted by Marketing

IBM released a whitepaper on Leveraging the Cloud to transform Test and Development. As companies implement software in the cloud on an on-premise platforms for workload sharing, challenges emerge in the movement of that workload between the customer premise and the offsite destination of that data. Does development become hindered if I move that workload offsite or does it have to be in my LAN? Can I move it offsite so workload mobility, flexible system and software configuration, and continuous provisioning be leveraged as a cost effective solution? IBM’s Smart Cloud solution and HyperIP’s WAN Acceleration Virtual Appliance ensures that customers can leverage workload mobility over the WAN, without suffering the performance problems caused by the WAN.
Customers leverage many techniques for moving the workload between the test/dev environment and the customer’s developers. vMotion, Live Migration, FTP, RSYNC, TSM, ProtecTier, etc. All of these applications require the workload to traverse the WAN. TCP/IP has limitations on the movement of big data. HyperIP removes those limitations to significantly improve performance of workload mobility, in excess of 10-12x faster by providing a WAN Acceleration technology that removes packet loss, latency, and out-of-order packets from task. HyperIP then implements block-level data reduction algorithms to significantly reduce the time to move that workload to or from the cloud hosting facility. This all translates to cost effective network transfers and connectivity.

For more information on HyperIP and to request a trial, go to http://www.netex.com .

This entry was posted in HyperIP, and tagged , , , , , , , , , Bookmark the permalink.

Continuation of TSM 6.3 Replication testing over HyperIP

Posted by Marketing

We recently had an opportunity to test IBM Tivoli Storage Manager (TSM) release 6.3 replication in our HyperIP lab. IBM just released this feature as part of their TSM 6.3 release in November. As stated in our previous Blog entry about TSM Backup testing, http://www.netex.com/blog/?p=175, it is important to first determine the overall limits of the native application before WAN acceleration.

Our test configuration included two HyperIP WAN Optimization virtual appliances, two windows servers running TSM 6.3, and a distance simulator for the WAN. The WAN simulator has the ability to inject packet loss, network latency, and other network conditions over various bandwidths that can degrade replication performance.

Like many other applications, replication is designed for the datacenter – to – datacenter movement of corporate data. Most replication applications perform very well when moving data over short distances, or in a metro environment. Customers running TSM Replication, in many cases, will need the remote site to be extended over the WAN, to an internal DR site, DR Service Provider, or Cloud Storage Provider. Any time distance is needed, network conditions such as latency and packet loss can significantly degrade application performance and become a huge impact on the throughput and application efficiency.

In our lab when latency and packet loss is experienced TSM native replication performance slowed by over 80% due to the typical inefficiencies of the TCP transport and not necessarily the fault of the TSM application. When HyperIP was added to the configuration, TSM Replication was able to achieve throughput equivalent to native performance and no delay. In fact HyperIP was able to help TSM Replication achieve near native line speeds at distances represented by 40 ms RTT, 80 ms RTT, 320 ms RTT all the way up to a 1 second RTT. TSM Replication over HyperIP proved to perform quite well at any distance, even with a significant amount of packet loss. In some cases HyperIP will accelerate TSM Replication by 6X. If 2:1 compression is possible then the TSM acceleration with HyperIP may approach 12X. Check it out for yourself. Download HyperIP by clicking on the big orange box above.

Want more information about TSM performance with HyperIP? Send an email to info@netex.com.

Links to our Product information and Best Practices are found here:
HyperIP product info: http://www.netex.com/hyperip
TSM Best Practices with HyperIP: http://www.netex.com/index.php/download_file/view/301
Become a HyperIP reseller: http://www.netex.com/partners/register
IBM PartnerWorld Link: HyperIP Virtual WAN Optimization
IBM Tivoli Storage Blog Link: NetEx HyperIP Accelerates TSM Replication

 

This entry was posted in HyperIP, and tagged , , , , , , , , , , , Bookmark the permalink.

HyperIP Series – You Asked About TSM Testing with HyperIP..

Posted by DaveHuhne

We recently had an opportunity to test IBM Tivoli Storage Manager (TSM) Client to a TSM Server in our HyperIP lab. When doing any kind of application verification or performance testing it is important to first determine the overall limits of the native application with and without WAN acceleration.

Lab testing in an emulated environment is a good way to test applications because you can mimic certain network topologies and characteristics. In our case the HyperIP lab consists of two HyperIP WAN Optimization virtual appliances, two windows servers, and a distance simulator for the WAN. The simulator has the ability to inject packet loss, network latency and other network conditions over various bandwidths that can degrade application performance.

The main objective with any test is to try to validate whether the HyperIP can accelerate the application over various distances with varying latency and packet loss scenarios. Every application has its own performance characteristics and limitations. The same is true for WAN networks. They are about as unique as fingerprints.

Like many backup applications TSM was designed for the data center and performs very well when moving data short distances. Since we are truly becoming a global society is it important to be able to move data over longer distances which is clearly a requirement of cloud storage environments.

With the case of IBM TSM, we started off testing with a simple delay of 10 ms round trip time (RTT). At this relatively short distance TSM slowed by 80% compared to its native performance. This is typical application degradation due primarily to the inefficiencies of the TCP transport and not necessarily the fault of the TSM application. When HyperIP was added to the configuration, the TSM application was able to achieve throughput equivalent to native performance and no delay. In fact HyperIP was able to help TSM achieve near native performance rates at distances represented by 40 ms RTT, 80 ms RTT, 320 ms RTT all the way up to a 1 second RTT. This is a testament to how well TSM and HyperIP interoperate together.

Many applications have internal limitations such as outstanding operations, queue size, or queue depth that artificially restrict the application’s ability to maximize throughput. That was certainly not the case with TSM. TSM can certainly pump data over the network when it is not encumbered with TCP performance issues. When operating TSM with HyperIP, the two combined can sustain the same throughput rates whether running across town, across the ocean, or around the world. That was very impressive. TSM over HyperIP brings LAN-like performance to WAN-based remote backups.

 

This entry was posted in HyperIP, and tagged , , , , , , , , , , Bookmark the permalink.

HyperIP Series – You Asked About Multiple Interfaces….

Posted by DaveHuhne

Everybody tells me this is going to be easy so I’m finally going to try HyperIP. Now let me see again where is the HyperIP website. Okay I’ve downloaded the OVF file, now what? Oh yeah, I need to watch the HyperIP Support Tutorial videos on their website. Very cool, these HyperIP guys sure try and make it easy for us rookies. I like that.

Now what’s next? Oh install the Virtual Appliance on my virtual platform (VMware ESX or Microsoft Hyper-V) and start configuring. Makes sense. Wait a moment it looks like I need management and data ports. I only have one NIC on my server. Hmmm… what do I do now?

We’ve heard this type of story a few times and want to take this opportunity to clarify some interface points. HyperIP has two interfaces; a data and management port. The data interface is used for all traffic using the HyperIP tunnel and may also be used to manage HyperIP. The management port is available when a separate management network is required. If the management interface is used, be sure to set up routing in the HyperIP so traffic takes the proper path.

Okay I have my management and data ports configured and am having trouble sending any traffic, what’s up? The most common issue we’ve seen here is from the interfaces being on the same network. The management and data ports cannot exist on the same subnet. If a second subnet is not available, use only the data port in your configuration.

Okay I have my management port pointing out the WAN and the data port on the LAN, why aren’t the HyperIPs able to communicate? The HyperIPs only talk to each other on the data interfaces. No traffic flows between the data and management ports.

Okay I have the two interfaces configured on the networks that will be sending traffic across HyperIP and only some servers can communicate. Why is that? HyperIP acts like a one-armed router where traffic using HyperIP comes in, and is sent out, on the same data interface. The data interface will be used for servers and storage that will utilize HyperIP. If the HyperIP cannot be placed in the same network as the servers and storage, routes or access lists can be used in routers to direct traffic at HyperIP.

Alright I have both interfaces configured to the same VLAN and one NIC card. That should work shouldn’t it? The data and management interfaces cannot be on the same network. In this situation, only use the data interface for traffic and management. You will need to set user access to allow a browser on the data port.

Well I think that has answered my management questions.
Thanks very much HyperIP.

 

This entry was posted in HyperIP, and tagged , , , , , , , , , , Bookmark the permalink.

HyperIP Series – Works Great with IBM Tivoli Storage Manager (TSM)…

Posted by Marketing

Enterprise Remote Backup has become more of a reality than a perception with the advent of enterprise-class backup apps like Tivoli Storage Manager (TSM).  Building a central information archive using TSM Client to Server backups and restores can now be done over the WAN with the HyperIP WAN Optimization Virtual Appliance.  Case studies, such as this one, Triangle-Ireland, talk about reducing backup and recovery windows between 50%-90% over the existing WAN. Significant flexibility with software because HyperIP scales its virtual footprint from 1Mbs-800Mbs in the same virtual appliance.  This allows for a typical hub & spoke architecture from numerous remote sites back to a data center or offsite public or private cloud storage provider.  Whether there are 10 remote sites or 400, HyperIP scales to meet with the RTO’s of every site, cluster, or server, virtualized or not.

Tivoli Storage Manager Client or Server software has network tuning parameters and on-board compression as noted in: TSM Performance Tuning Guide.  TSM can offload TCP tuning and data compression to HyperIP to recover those precious cycles on their resident servers.  HyperIP has the ability to take over session management of the IP data stream and implement software-based, adaptive, block-level compression with no impact on the TSM servers.

For Best Practices for Deploying Tivoli Storage Manager over HyperIP, check out our documentation link: Best Practices for HyperIP Deployment.

Don’t just deploy Enterprise Remote Backup, but HyperIP it.
HyperIP is proud to be “Ready for IBM Tivoli” certified.

This entry was posted in HyperIP, and tagged , , , , , , , , Bookmark the permalink.

Subscribe to our Blog

With RSS feeds, you don't have to visit our site everyday to keep up to date. Simply subscribe to our blog via RSS or Email and our posts will come to you!

Subscribe
via RSS

Search Blog Posts

Search

Subject

Visit our Website visit arrow