Nojan Moshiri

Introducing: Long Distance VMotion with VMWare

Nojan Moshiri — Tue, 02 Feb 2010 22:46:27 GMT

It seems like I blinked and 2009 went by, but in that time I've been working on so many interesting projects at F5, I have a backlog of information to share with the community. The first post this year is about the long distance VMotion with VMWare's ESX system. This is a solution that enables the movement of live running virtual machine hosts from one data center to another.

The main problems in routing VMotion between data centers are latency, bandwidth, client traffic and security. In BIG-IP 10.1 we have a solution that compresses, encrypts and shields the ESX servers from prevailing WAN conditions, to enable long distance motion of running hosts. Take a look at the following screencast to see how this works:

In the chart below are some of the typical improvement times we see with long distance VMotion with BIG-IP. When latency goes up, VMotion is often not possible without BIG-IP in place. For example, with 100 ms of round-trip latency, on an OC3, a virtual machine that has one gigabyte of active RAM memory, takes roughly three and a half minutes to migrate across the WAN. If you were to try the same VMotion without BIG-IP in place, it would take more than 13 minutes and only succeed about half the time.

I'm excited about the types of architectures that can be enabled with this kind of solution in place. F5 is laying the ground work to make some exciting infrastructures possible

Have a look at the F5 deployment guide which describes how to set this solution up and how to architect new solutions across your data centers: http://www.f5.com/pdf/deployment-guides/vmware-vmotion-dg.pdff

Technorati Tags: vmware,VMotion,Long Distance,iSessions,GTM,BIGIP-LTM 10.1,BIGIP-WOM

F5 and SAP Integration - Auto configuration and monitoring under BIG-IP V10

Nojan Moshiri — Sat, 18 Apr 2009 03:44:40 GMT

Are there ways that F5 Networks and SAP can make your SAP operations simpler, more elegant and more automated, with appropriate controls in place to detect abnormalities?

With V10, F5 Networks is delivering three things: first, template based configuration support for SAP Enterprise Portal and Web Based SAP ECC Instances (so that a few questions and one submit button perfectly configures your instances). Second, integration with SAP's ASLR (described below) to automatically detect and help configure all available SAP instances (so that your hunt for SAP instance numbers and port numbers during configuration is over). And third, a complete monitor that individually logs into each configured SAP Instance and checks that instance's unique health status (and then reacts appropriately).

SAP and F5 Networks's partnership manifests itself in exceptional ways and participating in the SAP Enterprise Services Community, part of SAP's Communities of Innovation was one of these opportunities. SAP's idea was elegant and came with a very practical goal: SAP reached out to all of the networking partners and asked us how we can simplify SAP NetWeaver operations.

The initial presentation from SAP asked this high level question and presented a series of APIs that could be used to build these solutions. SAP challenged us with the analog of the fly wheel governor (pictured above); could we invent a system that controls SAP based on the current working conditions. Through a series of working sessions with SAP we went to work at F5 Networks to solve this problem and the results of our work will be presented at the Americas SAP User Group Meeting (ASUG) in May.

Our solution has three components, detection of SAP instances, configuration of SAP web instances (Portal or other web based ECC instances) for high availability, web acceleration and security and monitoring of SAP web instances from login to database for a complete picture of what is up and what is down. These steps are performed with the aid of the SAP Application Server List Retrieval (ASLR) API which is part of the SAP Message Server (standard on all SAP NetWeaver installations out-of-the-box).

Configuration - Support for SAP Enterprise Portal and all your Web Based SAP ECC instances.

With F5 Networks BIG-IP V10 templates for SAP ERP Portal and SAP ECC instances, configuring BIG-IP with advanced application delivery controls is accomplished with just a few questions to be answered on one single page. Below, you can see a screen shot of my BIG-IP and the templates we have available today, especially for SAP, Enterprise Portal and a more generic SAP ECC template for the installation of any additional SAP Web Based instances.

Detection - Integration with SAP ASLR to automatically configure all SAP instances. The hunt for SAP instance numbers and port numbers is over.

With the coming addition of SAP ASLR integration (planned for after the upcoming ASUG meeting), we will have the message server integration pictured below. While this may look like a very small number of questions, the template takes care of all of the aspects of configuring SAP Portal. Of note to me is how easy it was previously for customers to miss important optimizations even though we detail and clearly document these in our deployment guides (for example the SAP Deployment Guide for V9). With BIG-IP V10 SAP application delivery will be the fastest possible through the network, every time.

Now, by providing the SAP Message Server IP Address and port number, BIG-IP automatically retrieves and populates the SAP instances in the load balancing portion of the questionnaire. The hunt for instance numbers and port numbers is over, with the cooperation of ASLR and BIG IP Application Templates.

Monitoring - A complete monitor that individually logs into each SAP Instance and checks that instance's unique health status (and then reacts appropriately)

One of the shortcomings that F5 Networks has found with the APIs as they stand today is that although graceful shutdown is well detected by the ASLR API, more is needed to address unforeseen outages. We hope that with the community involvement this will be addressed in coming versions of the API.

To solve this issue now, our SAP templates install a series of health monitors to cover the state of SAP Web Instances up the entire stack. We begin with automatic configuration of ping and port monitors (which indicates the individual server or VM instance is up). We then configure a monitor which checks for HTTP/1.1 presence (which indicates that SAP Dispatcher is up) and finally we now will recommend the addition of a health monitor to log into the SAP Web Application portal and check for a specified piece of validation text (we then log out, of course). None of this configuration requires any command line interaction and can be delegated to SAP NetWeaver or Basis administrators. Below you can see that we allow the configuration of the login username, password and validation text all via the UI.

For more on this project from our wonderful partners at SAP I highly recommend checking out Joerg Nalik's post at the SAP Community Network: Catching Up with Deploying and Operations Automation.

Technorati Tags: SAP,NetWeaver,Server Operations,SAP Enterprise Services Community,SAP Portal

Mobile data - Where does it go?

Nojan Moshiri — Tue, 10 Feb 2009 19:00:29 GMT

I was excited to see our press release coverage today about F5 Networks and Bytemobile's ability to scale T-Mobile's 3G Network Capacity with our VIPRION product. The article mentions the "explosive" growth of data on mobile networks and how data network capacity has to be scaled to handle the tremendous growth. As a sentence, this all makes sense, and most networking professionals wouldn't give it a second thought; it's a data network and it needs to be scaled.

On the other side of this datacenter-centric story is the world we see around us from day-to-day. Most professional have some sort of mobile data device these days, from Apple iPhones, to Google Android to Blackberry devices, and no one is shy about using the mobile data services they come with. The missing connection for many people I talk to casually about mobile data is where exactly their data goes, in other words, what is the path of the data and where does it run into limits?

At home and work, our email, web pages and videos all take generally the same path. This is not so true with mobile networks. On mobile networks, Text messages (SMS) ride an out-of-band portion of the voice network (thus the 160 byte limitation), Blackberry email messages involve additional hops through RIM servers and involve their protocols as well, data such as web pages and other TCP content have yet another path. The over-the-air part is just one small part of this path.

I see the light-bulb usually go off when I ask people "Where do you think the data goes from your phone?" and they say "oh, I've never thought about that". To take a very high level view, when we make a request for a web page or a YouTube video from our 3G device, let's consider the path our data has to take.

The request goes from the mobile device via over-the-air radio frequency to a local cell site. This is the 3G network, and this is only the first "hop". Your mobile request has traversed the over-the-air network in the fastest available way today, but now what? It doesn't go straight to YouTube.

From the cell site it's either relayed to another cell site or relayed back via high-speed lines to the carrier's network. At this point, depending on the network, there might be another conversion process to get to the TCP network and the request finally enters the "data network". In most networks, there has to be an authentication process to authorize the connection. Once the request has entered the carrier's network, it gets processed by all the standard mechanisms (DNS requests, proxy servers, caches, etc). This datacenter is the single point that all data communication go through and carriers work day-and-night to optimize the speed and reliability of these datacenters.

Once you realize that every single subscriber to your carrier's network is going through that same network, you realize just how important it is, certainly equally important to the 3G network, if not more. Finally, once the request is processed it returns to the mobile phone via that great and speedy 3G network.

And this is why today's news is so exciting to me. Seeing investments being made at the Mobile Carrier's datacenter is good news for everybody. It's these investments that will ultimately enable the "feature XYZ" or background applications or many of the other wish list items we crave on our mobile devices. When people see the performance numbers of our VIPRION, they sometimes ask who could possibly push that much traffic, in the mobile providers we have one of the many examples of an answer to that question.

Technorati Tags: F5,Mobile,Data,VIPRION,T-Mobile,ByteMobile

Welcome to F5

Nojan Moshiri — Tue, 01 Jul 2008 00:18:45 GMT

First post! (Okay, I had to get that cliche out of the way).

I'm pleased to be joining the illustrious group of bloggers at F5 Networks. I'm looking forward to adding information from a former customer perspective and also information about SAP and Adobe, which will be my focus at F5 Networks.

As a new employee and former customer, my viewpoint is a bit like a kid's in a candy store right now. I've had the opportunity to delve into many of the nooks and crannies of our application delivery networking offerings and I'm just now seeing how so many of my previous projects could have been streamlined, accelerated, been deployed faster and cost thousands less with the right mix of application delivery networking.

Big-IP can do some amazing things, but as a Sys Admin I rarely had the time or opportunity to delve into all of the things it can do. I hope to help break down some of this time barrier for those of you that are Sys Admins out there by sharing some real world experiences. For the system architects out there, I hope that this information will help create solid solutions that cost a fraction of other alternatives, for your upcoming projects.

For me, on several projects, the ability to control and initiate URL rewriting at the load balancing layer created the ability to launch some projects on an amazingly accelerated timeframe. In one project (not on Big-IP unfortunately), our outside analysts had put a timeframe of several years on one migration project; with the help of layer 7 networking, we were able to cut that down to six months. That project was more than five years ago and the amazing thing is that the technology we used to pull that off looks downright primitive next to the capabilities of Big-IP Local Traffic Manager (LTM) and the modules that can reside on Big-IP LTM.

There are already piles of real-world implementation and performance data located in our solution center (link to the performance data section in particular: http://www.f5.com/solution-center/white-papers/#app-performance). I'm going to share some of my personal experiences with these results and implementations, especially around SAP and Adobe, but also around the Linux, Apache, MySQL, PHP/Python/Perl (LAMP) stack world.

Not every system administrator and network engineer who falls in love with the full proxy architecture of Big-IP LTM can come join F5 Networks, immerse themselves in the technology and learn all the inner workings, hopefully my experiences can bridge that gap.

Some of the topics I'll be delving into will include:

* Bridging the gaps between system administrators and network engineers through the use of Big-IP LTM partitions and profiles (delegated administration). And more importantly, why network engineers can safely balance the risks of handing over management access to people outside their group,

* Using Big-IP LTM and Web Accelerator to reduce system administration tasks on web servers,

* Building a cheaper disaster recovery solution using Big-IP and solutions such as link load balancing, global traffic management (GTM) and WAN Acceleration,

* Utilizing iControl to automate system administration tasks,

* Utilizing iRules to reduce complex web site monitoring tasks such a Omniture tracking, or measuring page load speeds.

The list goes on, but the theme will remain the same: getting system administrators and network engineers to bridge the gap, for each to give a bit of control to ultimately create a much more efficient infrastructure with somewhat limitless architectural possibilities.

del.icio.us Tags: Big-IP,iControl,Monitoring,System Administration,Network Engineering,Omniture,Metrics