VMware NSX Advanced Load Balancer (Formerly Avi Networks)

sheesh and I are from the avi networks team how many of you were familiar with avi networks what we did great thank you so we we got acquired into VMware over the summer last year and we're now part of the networking and security business unit within VMware what I want to do is just offer you guys a quick intro and discuss the architecture and then I'll pass it on to sheesh to give you guys a quick overview of how we integrate into the VMware ecosystems as well as do a demo of our load balancing and laughs so are we got it start back in about 2012 we have sold into some of the largest enterprises financial services tech media companies I like to say if you have ever transacted online payments bought a movie ticket or a concert ticket online or done online banking chances are that your transaction went through a B so we have a lot of customers including Adobe and Deutsche Bank and companies like that that that use our product for a variety of different use cases so I'll just set this up I mean not that this information is new to you guys but one of the ways that we explain to our prospects and customers what really our B is looking to solve is this problem of the time to market and the the modernization of the application infrastructure and the cost efficiencies that enterprises are trying to drive and a B is basically you know it was born to solve this problem of increased demands of the IT folks to deploy new applications deal with the application velocity and the changes as well as the the multi-cloud nature of most enterprises today so if you look at the picture here on the right you know a few years ago we spoke to a customer in the East Coast a large financial institution that talked about how cool it was that they could develop a VM vending machine experience for their developers and provide a self-service portal for when they needed computing resource and what they found out where quickly was once they did that they'd have to hurry up and wait for the load balancer to be provisioned because that was the piece that wasn't quite automated they would have to procure appliances or stand up a new piece of infrastructure to add a new bit to provision that application for production so this was a common problem that we heard from most enterprises so the the further challenges in terms of the hardware load balancers themselves is most of the time whether you're dealing with a specific you know appliance based load balancer in hardware or a virtual machine based virtual load balancer the architecture is the same so you deploy an active standby pair of appliances and when we speak with customers the average utilization of these appliances at any given time is at about somewhere between 15 to 20 percent and the stand by appliance of course is not used until there is a disaster scenario and this sort of active 10 buy pair is stamped out throughout the infrastructure across the data centers that they own and the the challenge of course with this is that why while you have all of this fungible capacity you can't really use it and it's a it's a major problem because you have to manually place the virtual machine in each one of these appliances when you have a new virtual service that you want to build you have to know exactly which appliance you're going to place it on what capacity that appliance has and if it ever reaches capacity it's not like you can use this pair capacity that is available you know and in fact one of our customers best described this says he knows all of his load balancers by name right he knows that Jim has spare capacity Sally there has an upgrade coming up and and so on he was joking in a way that's saying that you know this is why there are pets and and you know that this this and this model of pets versus cattle sort of plays itself out with every one of our customers the the other of course challenges that every single pair is administered individually and you have to you know go in and just policies for each one of them there's no centralized way for you to handle that and that's an operational complexity for a lot of enterprises and the last piece here is that these load balancers are quite not designed for the modern infrastructure right across multiple clouds across containers and micro-services type applications etc and then if you look at challenges that happen with load balancing in the public cloud you have a lot of the traditional automation challenges that you have with existing hardware load balancers addressed but with AWS and an azure there are you know sort of issues around preacher completeness and performance of these load balancers you have to stitch together a bunch of different tools for DNS for Web Application Firewall and capabilities and logging and analytics and so on and you know each of them is a siloed load balancing solution for that cloud if you need something that is consistent across multiple cloud environments you don't you don't really have a way to do that and then of course the last point here is that a lot of the traditional vendors have come up and said if you want to take your load balancer the load balancer to the cloud you have the option to take a virtual load balancer and put it in AWS and that works out you know as we all know who expensive it suffers the same sort of scalability challenges as well as the architectural limitations so how do we solve for this what is it what is required to happen in order to solve for these challenges my clicker is a little sensitive okay so on the the first thing that the ABI team did was they set out to essentially create and Sdn like architecture for load balancing and the first thing that they did was separate the control plane for application delivery from the data plane itself so you have service engines which are essentially the load balancers and a central controller that addresses the entire lifecycle of the data plane so the data plane itself is a very elastic fabric that can grow and shrink so you can spin up additional load balancers or reduce the number of load balancers that you're dealing with and the load balancers themselves can be deployed across on-prem environment cells as well as any public cloud in in bare metal environments so you could if a customer's is most comfortable with using a del Sur and putting a load balancer on it and consuming it as an appliance they can do that or they can put it in a virtualized infrastructure or a kubernetes based container environment as well for ingress and load balancing services there one of the other unique insights that the AVI founding team had was when we have a distributed fabric like this for load balancing you can essentially use the load balancers they're sitting in such a privileged location and the network being able to collect all of that application traffic intelligence that is going through them and so they the the service engines themselves provide telemetry in real-time to the controller and we actually are able to use about six hundred odd metrics that allows us to provide all kinds of application intelligence that Ashish will share with you in the demo section and so and the last piece here is the automation itself because we have this controller architecture we have cloud connectors to a variety of different ecosystems and so we can very quickly automate the entire infrastructure to deliver self-service to application developers so this architectural difference is what allows our B to essentially provide the same consistent load balancing services or web application firewall in services across different environments so let's take a look at what it takes to go from that monolithic single cloud appliance and with this architecture what we're able to do is deliver a application services fabric that consists of a chakra load balancer a web application firewall or a container based ingress service for kubernetes clusters and so on with OB so this this is the architecture this is the components of the platform what I want Ashish to do is walk you through the rest of the the deck here and how we fit into the VMware ecosystem as well as the demo so thanks Chandra Chandra gave you a brief introduction to the architecture right so let me take you to next into how we fit into different ecosystems and features in the use cases so it's the same solution that runs in any environment runs in a VMware environment it runs in a public cloud environment and it provides a set of services from load balancing GSLV web application firewall DDoS detection mitigation application analytics across any cloud and as VMware we are doing deep integrations with various VMware product portfolio this is the same product runs on any cloud but also within VMware product portfolio we're doing deep integrations with nsx with VCF with EUC the horizon and workspace one portfolio with ponzu with the kind of the container services and so on so just again it's a universal multi-cloud multi services solution and when you talk about features the left side of the screen talks about the features that you expect from a typical load balance or ADC as you call it product local load balancing layer four layer seven GS lb content switching caching compression auto scaling you will not find them in the appliance other appliances why it's a controller base architecture security for full valve stack SSL TLS DDoS your full policies from layer for the layer seven client authentication SSO it's a full stack ADC on the right hand side you'll find something that it's not in any of the other solutions it is full application infrastructure analytics in so talking about it I'll show you in a demo as well as a full centralized management and let me pause here and talk about central manager vs. central controller lot of companies talk about or we have a central manager well where does the policy decide where is the intelligence can I manage each appliance individually if the answer is yes external controller it's just a central just a manager right avi is a controller which means that's the only way to talk to the product you cannot manage individual service engines right the policy states a single place it's a fully multi tenant solution full are back ok to complete isolation of tenants and users and everybody can manage only their set of load balancers and not step on anybody else it is of course api's that's a given but we have on top of that we have ansible terraform VRA vro full SDKs all of that out of the box so the swag respect we'll talk about that and your built-in item and DNS as well and it's the same solution that also works across multiple use cases same bits same feature set same API you can use them on Prem you can learn in any native public cloud instead of ELB or app gateway and so on as well as VMC on AWS and in any communities environment again same bits same feature set one of our customers call it polyglot we take the form of the underlying infrastructure you do plan communities you deploy as a container you are in public cloud you deploys an ami or a VHD depending the cloud right it's off that it's not an appliance that's a key difference with that let's switch gears a little bit and talk about security and specifically wrath when we talk to customers they say wofe is important application at accident increasing we have to protect applications at the application the top layer including graph but 90% of those are not deployed today why because it's extremely complex right so when we build wofe in our product portfolio we make sure first of all it's not a point solution it's part of a feature suite full security feature suite from layer 3 layer 4 rules to SSL TLS to user authentication to layer 7 rules application rate limiting and on top of that is laugh so it's a fill full stack of security features all integrated with centralized policy and centralized intelligence we'll talk about that and specifically around wow the way we address these challenges were tied to the architecture right so the three common issues that our customers told us were it's complex we are worried about turning on valve because what if you made a mistake and if it does something is blocked we have no idea why the traffic was dropped why because it's opaque that is not enough int visibility and finally one of our customers told us that during the peak traffic we turn off laughs why oh because it'll kill our load balancers because every time you enable laughs it is very heavy CPU utilization that the raffle acquires and if you have an appliance that Chandra talked about where you have capped by a box capacity if you enable laughs you cannot serve the traffic the very address that was again centralized controller so centralized policy management with full learning automatic learning model in our in our path so it simplifies your policies rich visibility in analytics and again I promise you I'll show you and third scale out architecture as the traffic grows you add capacity imagine you're deploying applications in AWS you don't fail at AWS Oh deploy a one gig load balancer you don't do that you don't say spin up a VM of this instance size no you said this is you call an API spin up in ELB as a traffic grows the he'll be automatically scales out application scale out well we give the same performance same experience on Prem or in public cloud right that's the beauty it's a cloud native solution regardless of where you're running specifically around graph and so those benefits go in and bath as well and so specific around bath we have a three-stage raft pipeline when the traffic comes in it first hits the whitelist engine and the job of the whitelist is this is where the customers have said I know that this is what I know my application URLs or my p addresses are known well-known just let them go through these are all well known traffic patterns so that hits the whitelist the most interesting stage and the most important stage is a positive security model this is where the system is auto learning ok this application has these patterns the URL looks like these it has these fields alphanumeric only and so on as a system learns it automatically allows that up traffic to go through quickly at a high performance and in the rest of the traffic then goes through the the signature engine where we provide both a default rule sets which with the streaming rules from our from our web poll as well as the customers can create the custom signatures as well so this is the negative security model so it's a three stage pipeline and as the the system learns the amount of traffic that hits the signatures is minimized resulting in higher performance okay this let me pause here this is was the end of the slides portion of it any questions before I go to the demo what's the next piece you got the load balancer yes a web application firewall yes without write up the rack well yeah there are there are set of layer for the layer seven services so as part of the VMware portfolio will integrate with NSX intelligence I think that Ray was just talking about and there are other layer for the layer seven services will talk about API gateway talk about anything that you do the application level right so so we have we have a plans to go into basically up the stack that's that's what it looks like the signatures yes how are you writing the signatures is it like yes model signatures or are you doing something else but these are vas signature so the system comes with default OS top ten protection so quadricep core rule set three CRS three dot oh but we also have streaming signature so we have a SAS portal from which you can stream the signatures directly says the new signatures become available they get streamed down to the controller customers can write their own signatures as well and you have documentation and guidance on writing the signatures yes yeah we support yeah we have a full documentation yeah your customers are running this in production for a few years now yeah very cool

Channel: Tech Field Day

Views: 5,784

Keywords:

Id: c1IP8ucDq3Y

Length: 17min 27sec (1047 seconds)

Published: Mon Feb 17 2020