View
0
Download
0
Category
Preview:
Citation preview
ElasticVirtualNetworkFunctionPlacementCloudNet 2015M.GHAZNAVI , A. KHAN, N . SHAHRIAR , KH. ALSUBHI , R . AHMED, R . BOUTABADAVIDR . CHER ITON SCHOOLOFCOMPUTER SC IENCE
UNIVERSITYOFWATERLOO
OutlineIntroduction
StateoftheArt
Problem:ElasticVirtualNetworkFunctionPlacement
Solution:SimpleLazyFacilityLocation
Evaluation
Conclusion
2 /30
IntroductionMIDDLE-BOXESNETWORKFUNCT IONVIRTUALIZAT ION
VNF SERVICESIN CLOUD
3 /30
Middle-Boxes“anyintermediarydeviceperformingfunctionsotherthanthenormal,standardfunctionsofanIProuteronthedatagrampathbetweenasourcehostanddestinationhost”[1]
Expensive hardware
Hard todeploy
Hard tomodify
Hard toscale
Provisionforpeak-load
[1]CARPENTER,B.,ANDBRIM,S.Middleboxes:TaxonomyandIssues.RFC3234,https://tools.ietf.org/rfc/rfc3234.txt,2002.[2]V.Sekar,N.Egi,S.Ratnasamy,M.K.Reiter,andG.Shi.Designandimplementationofaconsolidatedmiddlebox architecture.InProceedingsofNSDI12,2012.
𝑠𝑟𝑐 𝑡𝑟𝑔𝑚
Sourcehost
Middle-box
DestinationhostIDSFirewallIPS…
for in-network capabilities [9]. The lack of extensibil-ity in middleboxes today inevitably leads to further ap-pliance sprawl, with associated increases in capital andoperating expenses.
Despite these concerns, administrators reiterated thevalue they find in such appliances, particularly in sup-porting new applications (e.g., teleconferencing), in-creasing security (e.g., IDS), and improving performance(e.g., WAN optimizers).
3 CoMb: Overview and OpportunitiesThe previous discussion shows that even though middle-boxes are a critical part of the network infrastructure,they remain expensive, closed platforms that are diffi-cult to extend, and difficult to manage. This motivates usto rethink how middleboxes are designed and managed.We envision an alternative architecture, called CoMb,wherein software-centric implementations of middle-box applications are consolidated to run on a sharedhardware platform, and managed in a logically central-ized manner.
The qualitative benefits of this proposed architectureare easy to see. Software-based solutions reduce the costand development cycles to build and deploy new mid-dlebox applications (as independently argued in paral-lel work [12]). Consolidating multiple applications onthe same physical platform reduces device sprawl; wealready see early commercial offerings in this regard(e.g., [3]). Finally, the use of centralization to simplifynetwork management is also well known [31, 21, 15].
While the qualitative appeal is evident, there are prac-tical concerns with respect to efficiency. Typically, mov-ing from a specialized architecture to one that is moregeneral and extensible results in less efficient resourceutilization. However, as we show next, CoMb introducesnew efficiency opportunities that do not arise with to-day’s middlebox deployments.
3.1 Application multiplexingConsider a WAN optimizer and IDS running at an enter-prise site. The former optimizes file transfers betweentwo enterprise sites and may see peak load at night whensystem backups are run. In contrast, the IDS may seepeak load during the day because it monitors users’ webtraffic. Suppose the volumes of traffic processed by theWAN optimizer and IDS at two time instants t1, t2 are10,50 packets and 50,10 packets respectively. Todayeach hardware device must be provisioned to handle itspeak load resulting in a total provisioning cost corre-sponding to 2 ⇤ max{10,50} = 100 packets. A CoMbbox, running both a WAN optimizer and the IDS on thesame hardware can flexibly allocate resources as the loadvaries. Thus, it needs to be provisioned to handle thepeak total load of 60 packets or 40% fewer resources.
0
0.2
0.4
0.6
0.8
1
0
7
-
0
9
,
0
6
:
0
0
0
7
-
0
9
,
1
7
:
0
0
0
7
-
1
0
,
0
4
:
0
0
0
7
-
1
0
,
1
5
:
0
0
0
7
-
1
1
,
0
2
:
0
0
Norm
alized utilization
Time (mm-dd,hr)
WAN optimizer
Proxy
Load Balancer
Firewall
Figure 1: Middlebox utilization peak at different times
Session'Management'
Protocol'Parsers'
VPN WanOpt IDS Proxy
Firewall
Figure 2: Reusing lower-layer software modules acrossmiddlebox applications
Figure 1 shows a time series of the utilization of fourmiddleboxes at an enterprise site, each normalized by itsmaximum observed value. Let NormUtiltapp denote thenormalized utilization of the device app at time t. Now,to quantify the benefits of multiplexing, we compare thesum of the peak utilizations Âapp maxt{NormUtiltapp}= 4and the peak total utilization maxt{Âapp NormUtiltapp}=2.86. For the workload shown in Figure 1, multiplexingrequires 4�2.86
4 = 28% fewer resources.
3.2 Reusing software elementsEach middlebox typically needs low-level modules forpacket capture, parsing headers, reconstructing sessionstate, parsing application-layer protocols and so on. Ifthe same traffic is processed by many applications—e.g.,HTTP traffic is processed by an IDS, proxy, and an appli-cation firewall—each appliance has to repeat these com-mon actions for every packet. When these applicationsrun on a consolidated platform, we can potentially reusethese basic modules (Figure 2).
Consider an IDS and proxy. Both need to recon-struct session- and application-layer state before runninghigher-level actions. Suppose each device needs 1 unitof processing per packet. For the purposes of this ex-ample, let us assume that these common tasks contribute50% of the overall processing cost. Both appliances pro-cess HTTP traffic, but may also process traffic uniqueto each context; e.g., IDS processes UDP traffic whichthe proxy ignores. Suppose there are 10 UDP packetsand 45 HTTP packets. The total resource requirement is(IDS = 10+45)+ (Proxy = 45) = 100 units. The setup
Middle-box utilizationpeakatdifferenttimes[2]
4 /30
NetworkFunctionVirtualizationVirtualization(Softwarization)ofmiddle-boxes
Softwaremiddle-boxesarecalledVirtualNetworkFunction(VNF)
NFV”involvestheimplementationofnetworkfunctionsinsoftware thatcanrunonarangeofindustrystandardserverhardware,andthatcanbemoved to,orinstantiated in,variouslocationsinthenetworkasrequired,withouttheneedforinstallationofnewequipment.”[1]
[1]"NetworkFunctionsVirtualization".ISGwebportal:https://portal.etsi.org/nfv/nfv_white_paper.pdf
𝑣𝑠𝑟𝑐 𝑡𝑟𝑔
Sourcehost
VNF
Targethost
5 /30
NetworkFunctionVirtualizationMIDDLE-BOXES
Expensive hardware
Hard todeploy
Hard tomodify
Hard toscale
Provisionforpeak-load
VIRTUALNETWORKFUNCTIONS
Low-costsoftware
Easy todeploy
Easy tomodify
Easy toscale
Scaleresourcesondemand
6 /30
VNFServicesinCloudOfferedbycloudproviders◦ IBMBluemix◦ MicrosoftAzure◦ AmazonEC2
Services◦ RiverbedSTEELHEADWANoptimizer [1]◦ McAfeeNextGenerationfirewall[2]◦ VirtualLoadMaster loadbalancer[3]
[1]http://media-cms.riverbed.com/documents/Spec+Sheet+-+Steelhead+Family+-+05.06.2015.pdf[2] https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/25000/PD25151/en_US/NGFW_57_HW_Requirements.pdf[3] http://kemptechnologies.com/files/downloads/documentation/Datasheets/VLM-AWS.pdf
Client Cloud-Provider
VNFServiceRequest
7 /30
VNFServicesinCloudWHATCLOUDPROVIDERSHOULDSUPPORT
Payperuse◦ Clientspayonly forrealusedresources
Elasticity◦ Scaleresourcesondemand◦ Uponarrivalordepartureofservicerequest◦ Variationofworkloadofadmittedservicerequest
CHALLENGESOFCLOUDPROVIDER
MinimizingCosts:◦ Trade-off betweenHost&BandwidthResources
Elasticity◦ Whichmechanismstoapply◦ Elasticitybenefitvs.itsoverhead
8 /30
VNFServicesinCloudWhere toplaceVNFinstances?
Whichrequestmustbeassigned towhichVNFinstance?
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
9 /30
VNFServicesinCloudAsolutioncanbe◦ 𝑣) servesthefirstandsecondservicetraffics◦ 𝑣( servesthethirdandforthservicetraffics
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+
𝑣) 𝑣(
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
10 /30
StateoftheArtCOMPARISONOFSTATEOFTHEART
11 /30
ComparisonofStateoftheArtPaper HostRes.Cost BandwidthRes. Cost Elasticity
ElasticVirtualNetwork FunctionPlacement(EVNFP) ✔ ✔ ✔
ElasticityinCloud [1,2,3] ✔ ✕ ✔
Dynamic VMPlacement[2,4] ✔ ✕ ✔
NetworkAwareVM Placement[5,6,7] ✔ ✔ ✕
VirtualDPIPlacement[8] ✔ ✔ ✕
[1]Z.Gong,X.Gu,andJ.Wilkes.Press:Predictiveelasticresourcescalingforcloudsystems.InIEEECNSM,2010[2]U.Sharma,P.Shenoy,S.Sahu,andA.Shaikh.Acost-awareelasticityprovisioningsystemforthecloud.InIEEEICDCS2011.[3] Z.Shen,S.Subbiah,X.Gu,andJ.Wilkes.Cloudscale:Elasticresourcescalingformulti-tenantcloudsystems.InACMSoCC,2011.[4] A.Verma,P.Ahuja,andA.Neogi.pmapper:Powerandmigrationcostawareapplicationplacementinvirtualizedsystems.InACM/IFIP/USENIXMiddleware,2008.[5]O.Biranetal.A stablenetwork-awarevm placementforcloudsystems.InCCGRID,pages498–506,2012.[6] V.Mann,A.Kumar,P.Dutta,andS.Kalyanaraman.Vmflow:Leveragingvm mobilitytoreducenetworkpowercostsindatacenters.InIFIPNETWORKING,2011.[7] X.Meng,V.Pappas,andL.Zhang.Improvingthescalabilityofdatacenternetworkswithtraffic-awarevirtualmachineplacement.InIEEEINFOCOM,2010.[8]M.Bouet,J.Leguay,andV.Conan.Cost-basedplacementofvdpi functionsinnfv infrastructures.InNetSoft,2015.
12 /30
Problem:ElasticVirtualNetworkFunctionPlacement(EVNFP)SCOPEANDASSUMPTIONSCONFLICT ING OBJECT IVES
ELAST IC ITYMECHANISMSANDOVERHEAD
13 /30
ScopeandAssumptionsSCOPE
Singlecloudprovider
Singledata-center
Centralizedoptimization
ASSUMPTIONS
OneVNFinstance-type
Multi-tenancy
ElasticityMechanisms◦ HorizontalScaling◦ MigrationofVNFinstances◦ Reassignmentofworkload
14 /30
ConflictingObjectivesMinimizingthebandwidthcost,and
MinimizingthenumberofinstalledVNFs
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
15 /30
ConflictingObjectivesMinimizingthebandwidthcost:◦ 12 UnitofBandwidthover12 Links◦ 4 VNFinstances
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+𝑣)
𝑣+𝑣( 𝑣*
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
16 /30
ConflictingObjectivesMinimizingthenumberofinstalledVNFs◦ 1VNFinstance◦ 34 UnitofBandwidthover20 Links
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+
𝑣)
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
17 /30
ElasticityMechanismsandOverheadMECHANISMS
HorizontalScalingofVNFinstance◦ Installing anewVNFinstance◦ RemovinganexistingVNFinstance
MigrationofaVNFinstance
Reassignment ofworkloadtoanotherVNFinstance
OVERHEAD
Migration overhead
Reassignment overhead
18 /30
ElasticityMechanismsandOverhead
�
����
����
���
����
����
���
�
����
���
���
����
���
���
��
�
����
���
����
���
��
�
���� ������
�
����
����
VNF instance
Source of service traffic �
Target of service traffic �
Service traffic increase
Service traffic decrease
InitialPlacement
Migrationof𝑣
𝑣∗ InstallationandReassignment
Removing𝑣
1 2
3 4
19 /30
Solution:SimpleLazyFacilityLocation(SLFL)IDEA
SLFL:SIMPLELAZYFACILITYLOCATION
20 /30
IdeaArrivalanddepartureofarequest,orworkloadvariationalterthelocality
SLFLlocallyoptimizes theplacementofVNFinstancesinagreedymanner
𝑠𝑟𝑐( 𝑡𝑟𝑔(
𝑠𝑟𝑐)
𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+
𝑣) 𝑣(
𝑣 VNF instance
𝑠𝑟𝑐 Source of Service Traffic
𝑡𝑟𝑔 Target of Service Traffic
Network Switch
Host
𝑠𝑟𝑐*
𝑡𝑟𝑔*
21 /30
SLFL:SimpleLazyFacilityLocationUPONREQUESTARRIVALORWORKLOADINCREASEInstallationpotential◦ Installing aVNFinstance◦ Setofreassignments◦ Thedifferenceofoperationalcostbefore andafter installing theVNFinstanceandreassignments
Migrationpotential◦ Migration ofaVNFinstance◦ Thedifference ofoperationalcostbefore andafter migrationoftheVNFinstance
UPONREQUESTDEPARTUREORWORKLOADDECREASERemovingpotential◦ Removing aVNFinstance◦ Setofreassignments◦ Thedifference ofoperationalcostbefore andafter removingtheVNFinstanceandreassignments
Emigrationpotential◦ Migration ofaVNFinstance◦ Thedifference ofoperationalcostbefore andafter migrationoftheVNFinstance
22 /30
SLFL:SimpleLazyFacilityLocationUPONREQUESTARRIVALORWORKLOADINCREASEApplythebestactionamong:◦ InstallingaVNFinstance◦ Considering theinstallationpotential
◦ MigratingaVNFinstance◦ Considering themigrationpotentialoftheVNFinstance
◦ Assign tooneofexistingVNFs◦ Considering bandwidthcost
UPONREQUESTDEPARTUREORWORKLOADDECREASEApplythebestactionamong:◦ RemovingaVNFinstance◦ Considering theinstallationpotential
◦ MigratingaVNFinstance◦ Considering theemigrationpotentialoftheVNFinstance
23 /30
EvaluationEXPERIMENTALSETUPANDOBJECT IVESACCEPTANCERAT IOANDOPERAT IONALCOST
RESOURCEUT ILIZAT ION
24 /30
ExperimentalSetupandObjectivesEXPERIMENTALSETUP
Network◦ Fat-treeof99nodes◦ 54hostswith8CoreCPU◦ 1GBfullbisectionbandwidth
VNF◦ BroIDS[2]:80Mbps,1vCPU,1GBofmemory
Requests◦ 20,000requests◦ Arrival:Poissondistribution◦ Duration:Exponentialdistribution
OBJECTIVES
Evaluating◦ Theacceptanceratio◦ Operationalcost◦ Balancingbandwidth andhostresourcecosts
◦ ResourceUtilization◦ Balancingbandwidth andhostresourceutilization?
Comparisonto◦ RandomPlacement◦ First-FitPlacement
25 /30
AcceptanceRatioandOperationalCostACCEPTANCERATIO TOTALOPERATIONALCOST
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100
120
140
Cos
t(¢p
er20
0se
c.) Random
SLFLFirstFit
SLFLaccepts~2×workloadvsbasicalgorithmsSLFL 97% acceptanceratioRandom 48% acceptanceratioFirstFit 45% acceptanceratio
SLFLaccepts~2×workloadwithlesscost9%operationalcost lessthanRandom4% operationalcostlessthanFirstFit
26 /30
ResourceUtilizationBANDWIDTHRESOURCEUTILIZATION HOSTRESOURCEUTILIZATION
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
82% Utilizationofbandwidth resources91% Utilizationofhostresources
27 /30
ConclusionSUMMARY
28 /30
SummaryElasticVirtualNetworkFunctionProblem◦ Bandwidthandhostresourcescosttrade-off◦ ElasticityOverhead
SimpleLazyFacilityLocation◦ Balancingthebandwidthandhostresourcecosttrade-off◦ Carefullyselectingthecorrectelasticitymechanisms◦ Optimizing theelasticityoverhead◦ Accepting~2× workloadvsbasicalgorithms
29 /30
30
AcceptanceRatioandResourceUtilization
BandwidthResourceUtil.
VNFsUtil.
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
AcceptanceRatioHostResourceUtil.
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100RandomSLFLFirstFit
OperationalCost
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100
120
140
Cos
t(¢p
er20
0se
c.) Random
SLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100
120
140
Cos
t(¢p
er20
0se
c.) Random
SLFLFirstFit
0500
0100
00150
00200
00250
00300
00350
00400
00
10−5
10−4
10−3
10−2
10−1
100
101
¢per
200
sec.
ReassignmentMigration
0500
0100
00150
00200
00250
00300
00350
00400
00
Time (s)
0
20
40
60
80
100
120
140
Cos
t(¢p
er20
0se
c.) Random
SLFLFirstFit
TotalOperationalCost
BandwidthResourceCost
HostResourceCost
ElasticityOverheadCost
Assumptions-HorizontalScalingWhyhorizontalscalingandignoringverticalscaling◦ Ontheflyverticalresourcescalingisnotsupported inmostcases◦ Mightrequiresystemreboot◦ SLAviolation
Assumptions-OneVNFinstance-typeScenario Onesmall flavor Multiple flavors
ResourceConsumption
Host Res. ~ - Worse +Better
BandwidthRes. ~ +Better - Worse
Elasticity
Installation Ina samemachine +Better - Worse
Removal Ina samemachine +Better - Worse
Migrationoverhead ~ +Better - Worse
Reassign. overhead ~ =Equal =Equal
Recommended