Welcome!

@CloudExpo Authors: Pat Romanski, Zakia Bouachraoui, Elizabeth White, Liz McMillan, Yeshim Deniz

Blog Feed Post

v.10 - Introduction to iSessions

Amongst the wave of new features that came out in Version 10 of TMOS is a nifty little feature called iSessions. This being the first release of iSessions, there is a lot of curiosity and not as much documentation as we’d like yet. So I’ll walk you through what is available, why you’d want to use it, and what benefits it offers in this blog post. As time goes on we will expand our coverage of iSessions to more fully discuss all of the options and challenges they present.

The concept of iSessions in v.10 is pretty straight-forward… A secure tunnel between two BIG-IP systems to share in load-balancing and failover. The extension is that those BIG-IPs can be (and generally should be) geographically remote. Indeed, the whole point of iSessions is to make WAN communications faster, but we’ve got enough experience to know that some of you will find a use for them inside the datacenter. iSessions only require that the BIG-IPs be able to route between each other, not that they be geographically remote. Since optimization of traffic over an iSessions link is built in, you get both secure and accelerated WAN communications. The type of optimization is configurable, as are several other things about the tunnels.

While this post isn’t intended to be a step-by-step How-To document, it will give you an overview of the steps necessary to get your BIG-IPs talking on the “back channel”, and offer some points of interest for you to be aware of.

Much like some vendors have a remote office solution that is simply an optimizing proxy for their data center products, iSessions will forward requests to a remote BIG-IP. Unlike those solutions, if the connection the iSessions communicate over is down, the BIG-IP can be configured to handle the request locally if you have the servers in-place.

For this blog post we will refer to the “Data Center BIG-IP” and the “Remote BIG-IP” note that the “Remote BIG-IP” could be configured in an alternate data center, and thus could be fulfilling both the role of the Data Center BIG-IP in some instances and that of the Remote BIG-IP in others. For simplicity’s sake, we will not explore that configuration here, simply note that it’s possible. For this blog post, the “Remote BIG-IP” is the device that the user’s requests will come in through, the “Data Center BIG-IP” is the one that will ultimately service requests.

That should be all the background we need to cover, now on with the overview.

The best way to think of iSessions (for me at least) is like a fibre optic cable. iSessions are turned on at both Remote and Data Center BIG-IPs, and that creates the sheath that holds the fibres. When connections are requested on the Remote BIG-IP, an individual fiber (connection) is created in the sheath (tunnel). Depending upon your settings, that connection could exist for a long time, servicing repeated requests from different clients, or it could exist only so long as the requesting connection is live.

At its simplest, the iSessions configuration is easy. On the Remote BIG-IP, you configure a forwarding Virtual Server to forward requests to the Data Center BIG-IP. The Data Center BIG-IP has a Virtual Server configured for iSessions that either maps to a server or forwards to another Virtual Server on the same BIG-IP. Either way, the Data Center BIG-IP services the request, and sends the response along the same iSession connection, assuming the request is for the same target Virtual Server. Note that re-use has some drawbacks in every implementation out there, and you might want to consider their use carefully if you have very bursty traffic patterns. Also note that in this first implementation of iSessions, the longevity of a connection is 10 minutes and cannot be changed.

Note that the iSession Forwarding Virtual Server is different than most Forwarding Virtual Servers – it is configured as a standard Virtual Server with address/port translation turned off and no Pool object associated with it. A destination is then set that is the Data Center BIG-IP’s address. The Virtual Server on the Remote BIG-IP requires a TCP profile to be selected for both the client and server side contexts, and a client SSL profile must be selected so that iSessions info can be decrypted when the other BIG-IP sends responses.

This Virtual Server on the Remote BIG-IP also requires an iSession Profile to be selected so that tells the BIG-IP how to handle tunnel creation when communicating with the Data Center BIG-IP. The iSession profile specifically tells the BIG-IP about mappings to the Data Center BIG-IP, Session re-use, optimizations of the tunnel, and other general connection options like de-duplication (not currently available even if enabled… Check back for more info) and port transparency. Note that while the Endpoint Pool is slipped in at the bottom of the configuration screen, you need it set to a pool of one node that is the forwarding point for iSession Tunnels to the Data Center BIG-IP.

The Data Center BIG-IP has the same iSession Profile, and your choices for tunnel-specific configurations are compared when a tunnel is initiated, and only those settings that are enabled on both sides are used for this tunnel.

On the Data Center side, you must configure the iSession Profile such that it knows what to do with incoming connections – are they simply routed, or do they get sent to Virtual Servers for additional processing, etc. These options are at the bottom of the iSession Profile configuration. For Target Virtual type, your early implementations can probably use Match All, which will match to any Virtual that fits, and route the request on if none matches.

Okay, that’s a ton of info. We’ll call that the quick overview. The salient points are:

  1. iSessions create an encrypted, optimized tunnel over the WAN between two BIG-IPs.
  2. Both BIG-IPs must be v.10
  3. When configuring client and server profiles remember to think of traffic direction… Where the traffic comes in from the client (regardless of which BIG-IP you’re on) is the client side, where it flows back toward the client is the server side.
  4. iSessions are always encrypted but you have options for which and how much compression to use (and the ability to choose “adaptive” if you are uncertain which is best for you).
  5. Just because this blog post used “Remote BIG-IP” doesn’t mean it can’t also be in a data center, and in some instances it may even be the “Data Center BIG-IP” in highly distributed environments.
  6. Session re-use saves the overhead of renegotiating for each connection, but comes with a price of long-lived connections between the two BIG-IPs.

That’s it for now. I’ll be posting soon about how and why this is important if you’re considering using a cloud provider. Check with your SE if you’re interested in more implementation-specific details.

 

Don.

 

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
Despite being the market leader, we recognized the need to transform and reinvent our business at Dynatrace, before someone else disrupted the market. Over the course of three years, we changed everything - our technology, our culture and our brand image. In this session we'll discuss how we navigated through our own innovator's dilemma, and share takeaways from our experience that you can apply to your own organization.
Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Intel is an American multinational corporation and technology company headquartered in Santa Clara, California, in the Silicon Valley. It is the world's second largest and second highest valued semiconductor chip maker based on revenue after being overtaken by Samsung, and is the inventor of the x86 series of microprocessors, the processors found in most personal computers (PCs). Intel supplies processors for computer system manufacturers such as Apple, Lenovo, HP, and Dell. Intel also manufactures motherboard chipsets, network interface controllers and integrated circuits, flash memory, graphics chips, embedded processors and other devices related to communications and computing.
Digital transformation is about embracing digital technologies into a company's culture to better connect with its customers, automate processes, create better tools, enter new markets, etc. Such a transformation requires continuous orchestration across teams and an environment based on open collaboration and daily experiments. In his session at 21st Cloud Expo, Alex Casalboni, Technical (Cloud) Evangelist at Cloud Academy, explored and discussed the most urgent unsolved challenges to achieve full cloud literacy in the enterprise world.
Wasabi is the hot cloud storage company delivering low-cost, fast, and reliable cloud storage. Wasabi is 80% cheaper and 6x faster than Amazon S3, with 100% data immutability protection and no data egress fees. Created by Carbonite co-founders and cloud storage pioneers David Friend and Jeff Flowers, Wasabi is on a mission to commoditize the storage industry. Wasabi is a privately held company based in Boston, MA. Follow and connect with Wasabi on Twitter, Facebook, Instagram and the Wasabi blog.