私のプレゼンテーションを始めます。私はタカノリ・ミヤギシ・フロム・フジツです。そして、私はチャン・ユウ・フロム・ファウェイです。私のプレゼンテーションは、5パーツのビジョン・エシューズ、ソリューション・エホト・リバティ・フューチャル・プラムです。エホト・リバティ・パーツは、フジツ・ファウェイのアクティビティを説明します。まず、私はオープンスタックネットワーキングのビジョンを説明します。オープンスタックのデプロイエンタープライズシステムを作り、スケラビリティとアベラビリティを必要に必要です。必要なのは、スケラビリティは多くのブリエムのブリエムを作り、1000万ブリエムのブリエムを作り、アベラビリティは、絵の広がりのメニュータルが、ロングスタックネットワーキングのデプロイエンタープライズシステムを作り、ソリューション・タイムの仕事をしていると思います。はい。まず、アベラビリティビティのネットワークをたくさん試してみます。あとは、ネットワークのサービスについて ネットワークノードを使用するこのために 多くのネットワークトラフィックは ネットワークノードに通じていますアキテクチャーについては 何が起こっているか1つの問題は ネットワークノードはボトルネックのパフォーマンスである6つのネットワークトラフィックがあります2つの大きなキャラクターは 東北のトラフィックと 東北のトラフィック東北のトラフィックは 4つのトラフィックですトラフィックは 同じサービスと 同じサービスですトラフィックは DHCPサーバーに アクセスしていますそして トラフィックは メタデータから バーチャルルータですまず トラフィックは 同じサービスと 同じサービスですこのフィッシュは レッドアローはネットワークノードが通り コミュニケートを通りブリエムスは コミュニケートを通りネットワークノードを通り コミュニケートを通り2つのトラフィックは コミュニケートと 同じサービスのトラフィックが通りこの場合 トラフィックは ネットワークノードに通り2ノードのルートによるディスティニーション ホストVMを同じコンピューツノードに 行っている場合VMはネットワークノードに通信する必要があるVMの位置については 別のサーブネットについては3つのトラッキーはDHCPサーバーのトラッキーやVMの アクセスティングについてIPUのアドレスについてはVMがブーティングについてはDHCPサーバーはネットワークノードに 通信する必要があるそのため トラッキーはネットワークノードに通信する必要がある4つのトラッキーはVMが バーチャルルートからメタルデータを取り組んでいるVMがブーティングについては2つのトラッキーが 外側のオープンスタッグについてはオープンスタッグには2つの オープンスタッグについては1つはフローティングのIPについてはVMについては2つはSNETについてはこのトラッキーはネットワークノードに通信する必要があるここで6つのトラッキーがあります6つのトラッキーはネットワークノードに通信する必要があるそのため ネットワークノードはネットワークノードに 行く必要がある2つの問題は、ネットワークノードはフェリアのシングルポイントです。ネットワークノードが失敗すると、多くのトラフィックが影響することができます。Juno Releaseは、DBRやバーチャルラウターをインプリメントすることができます。DBRでは、L3エジェントとメタデータエジェントが同じコンピュートノードで、しかし、L3エジェントはSNATとDHCPエジェントが同じコンピュートノードで、DBRはディティブについて説明します。ネットワークノードはレガシルータと同じコンピュートノードで、まず、レガシルータのトラフィックを見てみましょう。5 out of 6 トラフィックは、ネットワークノードについて説明します。DBRでは、バーチャルラウターとフローティングIPをコンピュートノードで、コンピュートノードは、エクスタナルネットワークについて説明します。次のスライドでは、6 トラフィックを見てみましょう。同じサブネットのトラフィックはレガシルータで、同じコンピュートノードで、同じコンピュートノードで、バーチャルラウターのトラフィックで、コンピュートノードについて説明します。そのため、このトラフィックは、ネットワークノードで、ディエットサブネットワークノードで、そしてこのトラフィックはネットワークの通りに必要になります。VMのネットワークのメタダイトルで獲得したBatch Routerはメタダイトルで撮影することが出来ています。そのため、トラフィックはネットワークの通りに必要なのです。トラフィックはBatch Routerの通りに必要なのです、しかし、SNATのトラフィックはネットワークノードに向かっている。この行為は、3トラフィックはネットワークノードに向かっている。2DVRに向かっている。しかし、2トラフィックはネットワークノードに向かっている。つまり、2つの問題があります。ボトネックとシングルポイントの失敗。そのため、ボトネックとシングルポイントの失敗。SNATとDSCPの失敗は必要です。この特徴を実現するために、FujitsuはSNATを実現するために、FuawayはDSCPを実現するために、リバティについて説明します。次のページについて説明します。このように、SNATを実現するために、L3アジェントを実現するために、ネットワークノードに向かっている。まず、SNATの行為は、DVRモデルに向かっている。ネットワークノードに向かっている。バーチャルラータの使い方は、コンピュートノードに向かっている。ネットワークノード、バーチャルラータに向かっている。ネットワークノードに向かっている。バーチャルラータの位置に向かっている。この状況のCM10、この方法を使うために。この順序のサービスの無限的な品を使って、コミュニティについてお伺いすることができますもちろん each idea has pros and cons一つのことを見つけたはずは私のリースの理由はSNATはまだまだインプリメントされていません一つの理由はベストアイデアについてお伺いしますI'll explain the amount of public IP consumption by showing an actual number of consumptionin an example system configurationThere are two compute nodes, number one and number twoCompute node number one and number twohave two VMs of tenant number oneand VM of tenant number twoThe first idea is 1SNAT for one routerThis idea is the simplest implementationthat basically follows the current DVR behaviorBut the number of SNAT increases because each virtual router requires one SNATTherefore, the amount of public IP consumptionwill be number of virtual routerstimes number of compute nodesIn case of the example system configurationThree routers are distributed on two compute nodesSo the amount of IP consumption is sixThis idea might be accepted for small size environmentBut if the environment becomes biggerand increase the number of routers and compute nodesThe IP consumption will become too manyThe next idea is 1SNAT for one compute nodeThis idea consumes one IP per each compute nodeaiming to reduce IP consumptionIn other words, SNAT will be shared by different tenantson the hostTherefore, we need an exclusion of address scopebetween tenantsThe amount of public IP consumptionwill be number of compute nodesIt should be sufficiently smallIn this example system configuration, two IPs are consumedHowever, this idea has an issueThat is a security concerndue to sharing SNAT by different tenantsThen the third idea, 1SNAT for one compute nodewithout security concernis to solve this security concernstill trying to reduce IP consumptionWith this idea, SNAT will be sharedby virtual router of the same tenant in compute nodeThe amount of public IP consumptionwill be number of compute nodestimes number of tenantsHowever, if each tenant only has one virtual routerthe consumption will be the same as idea number oneIn the example system configuration4IPs are consumedThese three ideas actually increase the IP consumptionif you compare to the current SNAT modelThe remaining two ideas are to reduce the IP consumptionThen fourth idea is double NATWe have SNAT and an upstream physical routerSNAT is to translate private IP2 are dedicated to local IPlike ISP shared IP addressupstream physical routeris to translate the local IP to a public IPThis requires some changes to floating IP mechanismas it only handles public IPsIn addition, upstream physical routerneeds to be dynamically set upbut Newton doesn't have such a featureTherefore, to realize this ideawe need to develop the featureThe amount of public IP consumptionwill be number of virtual routerIt's same amount of current DVR modelThe last idea is BGP based ideaWith this idea, virtual routerin the same group share one public IPWe need an upstream physical routeras a gatewayBGP speaker uses BGP to advertise the routerwhich is not to connect in the same groupNeutron doesn't have a feature like BGP speaker yetRealizing this cost and relativity, highFor example, we need to develop BGP supportwhich we just should do right awayCapex relax server for BGP speakerSpecial requirements upstream physical routerthat support BGPThe amount of public IP consumptionwill be number of virtual routerIt's same amount of current DVR modelHowever, we need more enhancementfor BGP support to realize this ideaBecause the BGP speakerwill be another single point of failureI think possible solution is to makevirtual router behave as BGP speakerThen I summarize these ideasThe ideas in the order of the amountof public IP consumptionYou can see that ideas that many public IPs requireis doesn't need to pay cost for infrastructureI think distributed SNAT is trade off betweenpublic IP consumption and cost of infrastructureHutron plan of distributed SNATAt the design summit, I will propose idea number 3one SNAT for one compute nodewithout security concern againBecause it doesn't needIt doesn't need any specific hardwareAnd this idea haven't any security concernsAs you know, this idea still many public IPscan be consumed in a particular environmentIf you cannot get much advantagein your environment, you can choosecentralized SNATSorry, finally, let's discuss at the design summitI will discuss at Neutrons Contributor's Meetup on FridayFrom now, Chan will explain about distributed DHCPThank youGood afternoon everyoneMy name is Yu ZhangAnd I'm here presenting this topicon behalf of my colleague, Mr.Han Zhang ShiSo the topic is distributed DHCP agentIn fact, my partner has briefed youoverall picture of how we can remove the bottleneckand the single point failure on the Neutron Network nodeSo he has provided a big pictureAnd I just want to emphasize one pointone item in the big pictureIt's distributed DHCPSo three topicsThe first one is that we should reviewthe current status of DHCP agentor DHCP implementation in NeutronAnd second, we will go through the proposed distributedDHCP agent featureAnd the third is that we will have some road mapespecially in Metaka versionOkay, so this is a high-level architectureof current DHCP mechanism in current Neutron architectureOkay, so as we all know that we have controller nodeand on the controller nodewe will deploy Neutron serverSo Neutron server will collaborate with DHCP agentdeployed on the network nodeSo the DHCP agent will manageand especially it will spawn and managethe DNS mask processes as DNS serverswhich serves the DHCP requestsending out from the VMsin various tenant working networksOr more specifically, we can see thatfor each virtual networkwe will spawn at least one DNS maskprecise as a DHCP serverAnd in fact here, although we call it DHCPit is in fact some staticAP address assignment mechanismIn most cases, we just use DNS maskas a reference implementationSo here is a DHCP service workflowOkay, so to use a DHCP serviceprovided by NeutronIn general, we can consider the workflowinto five stepsThe first one is we shouldat first, we should create a networkfor a tenantand then on the networkwe should create subnetworkand then we should enablethe DHCP serviceSo those three steps is in generalfor a network and for a subnetworkAnd then for a VM level operationwe should at first create a podSo for a pod, we consider it asa virtual neck or something like thatAnd after that, we use this podto create a VMand after the VM is createdis provisionSo during the booting processof the guest operating systemthe operating system itselfwill send out a DHCP requestand this DHCP request will beserved by the DNS maskprecisededicated to thisvirtual networkand respond itassign fixed IP addressSo this is a whole workingworking flowNow let's talking aboutHAR or high availabilityAs we all know that in a productionlevel environment of OpenStackSo HA is always criticalSo how to achieveHA in the DHCP servicesSo at least we should providetwo or more network nodesthe deployment instancesSo for each of the network nodeswe should deploy one DHCP agentand this DHCP agent will beuse to managethe DHCP services on thisnetwork nodeand all of the DHCP agentsand the DNS mask processesworking in active active modeto provide a backup capabilitySo if one DHCP agent failor one DNS mask service failSo the other ones can take itover to provide the servicecontinuouslySo it can guarantee thatSo the service itselfis in a train modeNow we come to this pageSo although we haveFoundamental DHCP service capabilityWe have HA capabilityBut we also have someproblems to handleThe first is thatThe IP addressThe IP address is consumedFor each subnetworkSo each DNS mask precisewill consume one IP addressSo if we ask for HAThen at least two or moreFixed IP addresses will be consumedSo this is a kind of costAnd secondSo as we know thatFor each network nodeThe host level resourcesEither CPU and memoryAnd bandwidth and so onAre very critical in factSo because you know thatWe need the network nodeTo transfer to forwardThe network trafficBut if we justConsolidate all of theDHCP servicesThe DHCP DNS mask processesOn the network nodeThe DHCP service itselfWill also consume resourcesFor example, we need toCreate, we need toOccupy some CPUOccupy some memory and so onOkSo we can just assumeSuch a scenarioSo in a typicalOpenStack deploymentIt's very easy thatWe have hundreds or even thousandsOf virtual networksOk, so in such a caseThe results for managementConsumed on the networkNode itself is notIgnorableSo it's a problemAnd the fourth itemHere is thatIn some casesOk, just in some casesThere is a riskThat a VM cannotGet its fixed IP addressThe reason is thatSo when the Neutron serverJust send theIP address assignmentInformation out to theDHCP agentSo the DHCP agentWill rebootWill reboot the DNS maskPrecise to makeThe IP address configurationInformation workOk, so there is aPrecise of rebootingDNS maskSuch kind of rebootingWill interruptThe DNS maskThe DNS maskOr theDHCP serviceFor maybe a short timeMaybe just a short timeBut if it's unfortunateThat just during the short timeSome VMs send outDHCP requestAnd the request is receivedBy the network nodeThen in such a short timeIt cannot be servedAnd the VM cannot getFixed IP addressSo this is some problemIn a large deploymentOf OpenStackOk, so how to address thatI think we can get some hintsWe can get some referenceImplementation of NOAA NetworkOk, because in NOAA NetworkWe just have a multi-hostDHCP implementationOk, it can be a referenceSo this featureJust summarizeDHCP distributedDHCP agent ideaOk, we can see thatIn such kind of new implementationWe just deployDHCP agentOn each of the compute nodeEach of the compute nodeWe will have its ownDHCP agentAnd this DHCP agentIs only used to manageThe DNS mask processorsOn this compute nodeFor the VMHusted by this compute nodeOk, so there is a differenceWe can just imagine thatIn a typical environmentFor productionSo on each of the compute nodeTypically, we only haveTens of virtual machinesFor example, maybe 20 or 30Ok, and so it means thatAt most, on each compute nodeWe only need to hostMaybe 20 or 30Virtual networksSo we only need toCreate such kind of a numberOf namespaces forManaged virtual networkOk, so that isNot very very challengingIt's more easy to be implemented Than the consolidated network nodeOkAnd also we can see thatIn such kind of implementationSo all of the DNS mask processorsServing one virtual networkOn different compute nodesWe will share one IP addressOk, so whateverCompute node number isWe only has only oneFixed IP addressFor the DHCP serviceSo this is alsoKind of resource savingOkSo this pageJust shows the advantagesOf DHCP distributedDHCPCompared to the consolidatedTraditional DHCP implementationOkSo in generalWe think thatIt can save resourcesIt can removeOr it can reduceManagement trafficWorkflowNot the controller nodeBetween the Neutral serverAnd DHCP agentsBecause for each oneDHCP agentIt only needs toReceive the management informationThe MAC to IPMiping relationship informationFor this specificCompute nodeThere is not too muchVMS on this one nodeSo there is not too muchInformation for this nodeTo be transferredOkIt can help to reduceThe management trafficFor this nodeOkAnd of courseSince nowOne DHCP agentOnly manageDHCP servicesFor thisLocated compute nodeSo the scope of failureHas been limitedOk soThere is noSingle point of failureProblemForRodeMaps sideWe have made the specTo the Neutral communityAnd we plan to promoteIt in the communityAnd get it mergedIn one cycleThe codeAnd the first referenceImplementation will beBased on the OVS agentAnd we will manageThe DNS maskPrecise to provideThe DNS serverAnd also we willWe have the plan to supportThe internal DNSAnd after the firstThree itemsWe will have someOther future planTo supportThe other pluginsOr ML2 driversOk soThis is justThe workHuawei is tryingTo pushTo the Neutral communityOk thank you