マルチベンダー ネットワーク・サービス・オーケストレーション

迅速に設計、自動化し、物理および仮想ネットワークデバイスのための複雑なネットワークサービスのオーケストレーション

ネットワークオーケストレーションケーススタディ:F5シルバーラインDDoS攻撃防御

ネットワークオーケストレーションケーススタディ:F5シルバーラインDDoS攻撃防御

6月 26、2017 | Case Study



あなたが今日のあなたの車を起動したとき、あなたは覚えていますか?点火など、燃料ポンプがエンジンにガスを送っていたか、ピストンがクランキングされたかどうか働いていた場合、あなたは思いましたか?いいえ、あなたはしませんでした。次に、なぜネットワーキングチームは、ビジネスの意図をサポートするために、手動の方法でベンダーの百渡って、操作の数千人を扱っていますか?

マイク・レヒナー 彼はそのシルバーラインのDDoSプライベートクラウドの展開を拡大しなければならなかったときF5ネットワークから、同様の課題に直面していました。マイクはAnuta(ビッグネームのベンダーから)NCX、NSO、Ansibleとこの問題を解決するための人形など、複数のネットワーク・オーケストレーション・ソリューションを評価しました。マイクは、その柔軟性、マルチベンダー・カバレッジ、拡張性だけでなく、Anutaチームから優れたサポートのAnuta NCXを選びました。

彼はネットワークのオーケストレーションを導入する彼の旅を共有するようマイクを聴きます。



ポッドキャストトランスクリプト



前書き



00:01 Welcome to packet pushes the data networking podcast that repeatedly, predictably and reliably arrives in your podcatcher every week. In spite of the fact that it is hand cranked and artisanally crafted and manually published. The topic of infrastructure automation and orchestration is the toughest topic to discuss. And for every single company that's out there, the whole process of introducing automation and getting to the orchestration process is just different. There are so many people, there are so many areas that can be improved. It's just a tough place to start. In today's sponsored show we are talking with Mike Lechner from F5 Networks about his experience of Anuta networks NCX and how that's been helping them to deploy network services. Now Mike is the manager of product development at F5 Networks and is part of a team that operates the cloud services that offer DDoS protection and web application firewall. And that's become just a massive area of interest for enterprises for securing their internet gateways as the rise of security has made us all think. So let's get straight into it. First of all, Mike welcome to the show on the Packet Pushers, thanks so much for giving us your time today.

01:01マイク:ここにいるおかげで、素晴らしいです。

シルバーラインのDDoSクラウドインフラストラクチャへのイントロ



だから我々は非常に簡単にそれをキックオフいないもの。なぜあなたはF5の顧客のために一緒に入れている。このDDoS攻撃やWAFサービスが何であるかを要約していません。

マイク:あなたが認識しているとあなたのリスナーのほとんどが気づいているように、確かに。 F5は、伝統的にBIG IPのロードバランサを持っています。そして、我々の焦点は、セキュリティとクラウドの側面には少し異なっています。私たちのチーム、または部門の銀行。私たちは、銀行のDDoS保護および銀行のWebアプリケーションファイアウォールを提供します。そして、我々の顧客のためにその不良または汚れたトラフィックを取り、それをスクラブし、それらへのクリーンなトラフィックとして、それを返すように銀行のDDoS保護機能を備えた主なもの。


01:42だから、あなたがそのDDoS攻撃トラフィックの中に吸引し、検出の全体の束をやって世界中のインスタンスの全体の束を持っている意味します。それは私たちが話しているのスケールです。

マイク:それは正しいです。データセンターは、世界中に分散され、すべてのお客様のために我々はできる限りのパフォーマンスを得るためにアウトキャスト宣伝します。

NCXが果たすどのような役割を送っていますか?



02:02そして、マイク、あなたはこの製品を展開し続けることAnuta NCXで作業しています。

マイク:うん、正しいです。だから我々はそこに今日あるサービスを持っており、私たちがやっていることは集中し、私たちが必要としているサービスと駒を設定するには、カスタマポータルのための社内アプリケーションや作品のためのサービスおよびその他の内部のアプリケーションを統合支援するためでAnutaをもたらしていますへのお客様のために、私たちはオンボードのように変更を加えます。


02:32は大丈夫そう、我々はショーにAnutaを持っていたし、それがショーに年間で数回となっています。私たちは、彼らのプラットフォームについてのそれらに話しました。そして、主に、我々は、モデルベースのアーキテクチャを使用してネットワークデバイスを設定するツールとして、NCXに焦点を当てました。その何あなたの主な目的であるか、それよりも、それにあっもっとありますか?

マイク:まあ、それの第一段階は、抽象的、ビジネス・ロジックおよびデバイスは、特定のサービスのために設定される必要があるように、実際の装置にあります。だから我々はダウンしたと私たちは私たちの環境を統合する必要が異なる特徴と機能のためのさまざまな作業の流れを取りました。そして、我々はAnutaにそれを入れて、その構成データ及び増強サービスのための真のソースとしてAnutaを使用しました。だから、私たちの内部アプリケーションでの私たちのためにAPI層のようなものです。


03時24分、それはほとんどあなたのプラットフォームのコアのようなものだようなので、それは私に聞こえます。あなたはそれの上にいくつかのポータルを入れている、あなたはその周りにいくつかの開発をやった」しかし、それは、それはあなたのためにそのプラットフォーム全体の重要な一部だほとんどのようなものですか?


マイク:はい、私ははい、それがより多くを得ている、限りネットワーク構成などを意味します。そして、私たちが行うことを許可されているものので、アプリケーションの各のうち、コア機能と物流のようなものを取ることです。例は-whichスイッチがどのルータ設定、エリア、更新する必要がありますされています。我々はアウトその抽象できるとAnuta NCX内部の知性、その後、私たちの外側のアプリケーションはただちょっと、我々はDCエリアに展開する必要がある、と言って持っていることを置きます。そして、アプリケーションがどのようなデバイスやスイッチやルータとがある事を気にする必要はありません。

マルチベンダーのカバレッジ:



04時21分現在Anuta NCXは、マルチベンダープラットフォームです。あなたに有用である何かがありますか?あなたは本当にそこにさまざまなデバイスの多くを構成していますか?


04時27マイク:まあ、マルチベンダーは間違いなくあなたは、このような製品で探しものです。我々は我々のインフラストラクチャを構築していると私たちは私たちのインフラストラクチャを構築されたとして、あなたはまだ一種のそこにいくつかのキープレーヤーに焦点を当てました。しかし、彼らは常に、すべての部分で同じベンダーではありません。あなたは私たちのルーターを知っているよう必ずしも当社のスイッチ・ベンダーと同じではありません。そして、誰が新しい技術やあなたが戻ってそこに別のベンダーを置く必要がある場合は、そのような性質のもので、将来的に知っています。それはあなたがその特定のベンダーのためにコーディングする必要がないことを知ってうれしいです。

マルチテナントとスケール:



05:01 So you've got this situation where you've got a pretty substantial infrastructure, you are talking about taking a lot of load. Not only you talked about multiple-vendors but you also talk about multiple-regions. Now, two areas of real concern to me, which is multi-tenancy and also scaling quickly. Now those things that you've been able to look into and satisfy yourself with how that's going to go?

05:22 Mike: Yes, so just to clarify one point. The service we have today is up and running. We are just bringing Anuta into help us gear up for the future. And putting Anuta in place; what we see is that because you take some of the current applications and let's say, they are currently doing the device configuration. But say you have more than one application, so now who really owns that configuration. Like are they both caching the information? As far as configuration; so the immediate impacts we could see is if we use Anuta as a source of truth and we can roll out agents to each of the data centers to talk to the devices. It's a lot more quickly, right because they are local. But then instead of each application having to go to get that status because everyone is making changes and doing things. We can just query Anuta and get that status right from there.

なぜAnutaから購入しますか?



06:21だから、それは本当に重要なアプリのようになります。それは、私はあなたがそれのようないくつかの他のシステムを戻った想像し、バックエンドシステムのようになります。これはかなり大きくて複雑なシステムです。だから、おそらくいくつかの異なる自己開発されているそのうちのいくつかはそこにあるもの、及びNCXがあなたのためにやっていることのいくつかを持っています。なぜあなたは選択肢を考慮しNCXを買うでしょう。私は他のどのような選択肢あなたが考えると、なぜ一日の終わりにNCXを買った意味ですか?

Mike: Well, I mean that's a great question and the first two pieces are, you know do we actually need to by a third party vendor . Could we just build this ourselves? And that evaluation happened, but orchestration is tricky. And so for us we look at our department and decide if it’s the best use of our time. And it was determined that it wasn't. So then we go out and look for vendors. And our initial choice was actually a different platform from one of those other big vendors out there. And by the time we prioritize projects and the project got funding and everything else for that, we found three other competitors to that product. So it was really in our best interest to re-evaluate at that point. We were able to rule out the first two very quickly. But Anuta was different and it kind of bubbled up on a radar. So then we really did some good analysis and thought that this was a solution to go. Now obviously being a little risky, right because they are not as big and not as well-established there. But basically what the product was and the way that it's built and the way that it fits in our organization was great.

08:01 So when you went through the process you would’ve also gone through I'm sure the consideration of build or buy, right. Still how much development are you doing yourself and how much development have you saved by going straight to a pre-built platform like Anuta NCX?

マイク:だから、我々はまだいくつかの開発を行う必要があり、正しいです。そして、実際には別のことだ、我々はコストを上回る必要がありました。私たちは、Anutaに行っおよびプロフェッショナルサービスねえ、ここで我々が構築し、それを移動して、やろうとしているである、と述べている可能性があります。しかし、我々は異なるアプローチを決めました。私たちは本当に製品にスケールアップし、私達は種類の私達の自身の運命を制御できるように、それがどのように動作するかを学びたいと思いました。だから、フロントエンドにもう少し必要なものが、間違いなく、リスクの価値がありました。

モデリングに



08:41 That leads down to the discussion where; one of the big things we are talking about in Modern Network Orchestration tools is this concept of model-driven architecture. So you have a model, where you create it and then the Yang models that tool chain that you use to be able to handle the devices. One of the questions I always like to ask people. Did you have people problems introducing this model-driven type orchestration system?

09:04 Mike: No and actually Yang modelling was new to me was new to the team. But really when you start looking at it, it's not that tricky. Very similar to XML and some of the other mark-up languages and what I really liked about Anuta was they provide this NDK/SDK piece. And while it is an appliance and kind of a black box. The NDK really exposes you to lot of like existing models. So it's really easy to kind of investigate and look on how things are modelled; whether it's different, service types or different objects. And so the learning curve was pretty easy with that. And then using the development kit and putting in models was easy to kind of test those things out and go. But we definitely spent a lot of time on focusing and trying to get our modelling right to begin with. Because going back to the development piece, if you can get the Yang models really good, a lot of the SDK can generate a lot of the code templates and the module templates for you that just allows you to focus on the business logic piece. So it definitely eases in development.

10:16 Does that shift from device-centric networking or packets through the devices or network itself to standing back and doing the model? Has that transition been really powerful for you? Has it been simple enough to achieve? Would you give anybody some advice about how to approach that model-driven architecture and how to start thinking about that?

Mike: Sure, I mean the approach that I took was more of the service type model, right. What are we trying to provide? And again we were balancing it out of; do we want to build like 1000 different models and then have the application piece apart together? Do we want to build this one big monolithic model that handles all of our configuration? We kind of settled on the middle which was what really defines our service. Like if you are creating a customer or you are adding a customer endpoint or things of that nature. So abstracting the actual device stuff out and just providing like these API calls and then the way that you put them on dependencies and you actually hook service models to each to make sure that their dependents for your applications don't have to worry. You can tell them here is the order but if they choose not to do it, we can still check it and slide service model pieces there. And so that's the approach that we took. But more of what service are we providing and we look at all of our internal teams as customers. And so it's like what is going to make it easy for them? How can we sell it to them to use this product? So we try to make it as easy as possible.

なぜ人形/ Ansible?



11:54だから、多くの人が自分の設定を行うと、ネットワーク構成の彼らの自動化を行うために人形Ansibleの使用について私たちに話をしています。しかし、それはあなたが、私はサービス全体を構成しています、と言っている、あなたはそれを見ている途中から、私には聞こえます。あなたが実際にこのデバイスを取得するPupper / Ansibleのためのpythonのように、この書き込みコードにダウン得ていたなら、あなたは実際にあなたのサービスの問題のように得ていない可能性があります。あなたが話している途中から、あなただけのビジネスの側面に焦点を当てました。

Mike: Correct, so you are right. You could spend a lot of time in doing this but you are still; it's like someone has to do that business logic. Whether it's the outside application or where we chose to put it inside the Anuta piece there. So again to make it easy and friendly to use for these other applications. It is really extracting as much of the topology in the network as possible. You know using like a puppet or Ansible sure you can configure the device but you still have to be aware of the devices and all the things that go along or which steps to take. And that's where we kind of try to abstract that out in this orchestration. Because to me Puppet and Ansible are more of, how do I configure this switch or server or something like that. It just stops the repetitive task. Or orchestration - I'm saying hey, I want to add widget A. Who needs to know anything about widget A, and that's where like Anuta comes in for us.

組織の課題?



あなたはこれらのモデルを構築する際に13時14だから、これは組織横断的な取り組みの一種である、またはそれをある - 私は、ネットワーキング、このためのグループおよびそのためのアプリケーション・グループがありますか?みんなが周りのテーブルで最初の時間を取得し、のはを通じて、この全体のことをお話しましょう、と言っていますか?

Mike: So my approach was again looking at all the different teams as customers. And some customers in this case are a little more I guess priority than others. So I really looked at the networking team as being priority A customers. Because they are the devices, they are the ones who are getting called in the middle of the night if there are problems and those types of pieces. So I really focus on them first. And it was good because I'm not a network engineer by trade but I do know enough to be dangerous. So in talking with our networking engineering team, so what I had to do was kind of get a feel for; you know they have what needs to be configured and why. But I have a unique perspective because I'm not a networking engineer. So in working with the networking team I had a different perspective where you know I'm not sure how all the pieces fit together. So I ask different questions and things to look at it from that service way and build it out and try to map out dependencies and stuff. And that's what was really key for us and how we determine what service models to build. Because you know you are looking at things like, well, if I delete this piece, I want to make sure I don't delete other core pieces that things are responsible for, right. That are hooked into other models. So we kind of look at all those dependencies and things like that and kind of really craft it out; this is a service and that's a service and it's really easy to look at this service model here for a dependency if that makes sense.

車の類推



14時57分うん、私はそう思い、私はそれでやってみることができる場合、私はオタクにいることを回す場合は、言っていることを話す、あなたは一種のNCXプラットフォームだと思います。そして、それはこれらのモデルのすべてを持って、それはノースバウンドAPIのを持って、それがサウスバウンドAPIのです。そして、あなたはそこにすべてのモデルと作品を持っています。それはYANG、すべてを見ているので、ちょうど基本的にあなたが行くと、そのデバイスにこれを行う、と言っています。それは消灯し、あなたのためにそれを行います。 So all of a sudden you are not sitting there and thinking to yourself, if I get in that car I'm going to turn the engine on and then the Pistons have to work, and then the fuel line has to pump and blah-blah-blah and all that. And that's pretty much what you are doing when you use manual automation like Ansible and Puppet. You've got to think about an awful lot of those steps yourself. But Anuta, kind of takes that away from you because you just have to say, oh, I've got a cisco device or juniper device or an F5 device, whatever it is in the network, there is an YANG model for it. If I want to do this to it, it just self-generates the code for you and goes off and does that. And kind of that leaves you free to start thinking about, well, if I did this and put this in, then I can run this service flow. Am I reading that right?

15:59 Yeah, absolutely because the focus is not on what commands do I have to run on the device. It's like what are my rules for actually doing this configuration? So example, is like you go to add a customer, what's the first step? Well, the VLAN for a customer needs to be populated on all of the devices in the network; all the edge let's say. And so if our portal application has a new customer, it says add customer XYZ and then it doesn't know what devices, it doesn't know what data centers, it just knows at that point the VLAN is everywhere where it needs to be, and every other step. But then from my layer in using the SDK I can say, well, here are all the devices that we do configuration. It's a layer 3 interface and we add this VLAN on and by magic, the VLAN gets added in all the right places.

17:02 This to me is the shift, right. This is the shift away from doing something in CLI where the human had to translate the business intent into arcane mystic code that came out of their fingers into some command line, to moving towards the first step of automation which is ansible and puppet, which is actually all a lot of people can actually manage to achieve. Because you can only make small incremental changes. But if you can start to imagine an orchestration system like NCX which has the portals and the models and does a lot of that work for you. It seems to me like you just automatically stand right the way back from the actual network itself and you are really focused on just getting the regions setup. The tenancies are already configured. This thing happens, that thing happens, you can do the configuration checks and validations and dependencies check to make sure that things; because that's all taken care of in the NCX platform.

17時55マイク:はい、それは実際にネットワークや他のアプリケーションの右のようなデバイスを作っているし、他の人がそれで行くことができるということがそのAPIを入れていることは、私はこれらのコマンドをSSHおよびCLIんが、心配する必要はありません。 VLANは、それはそれを追加し、追加 - それは、すべての抽象化です。

役割ベースのアクセスとIPAM:



午前18時17分これは、すべての抽象化されます。私はちょうどAnutaソリューション自体に関するいくつかの質問をしたかったです。我々はオンライン来る前にチャットしたように、私たちは役割ベースのアクセス制御モデルとIPAMについて少し話しました。実際にそこにあなたの目やあなたの注意を引いたNCXについて何かがありましたか?

Mike: Yes, so one of the things with the Role Based Access, obviously you can set up users and permissions for the UI itself. But the access controls are very flexible. And so when you are designing your API's and exposing them, you can apply the same model to those API's as well. So you know making a set of read only calls or read and write calls and those things based off of the service models that we've developed ourselves. It's super configurable in that way. Everything from the product itself is basically like a layer of API's and you are able to control any portions of the roles and access and stuff and any portion of the product.

19:16 So I think that's important because you are building a multi-tenant system that is going to be administered by a central party. You really need to know that, that system right out. It's going to be integrated into other pieces in your particular situation. And it's going to be flexible enough. What about your IP address, are you managing that from NCX too?

マイク:だから、今日、私たちはそうではありません。だから、私たちは働いていた最初のフェーズは、私は抽象化レイヤを出してあげる[より良い用語の欠如のために]これを入れています。ビルNCXは、アプリケーションのためです。私たちはそこに私たちのIPアドレス、あるいは当社のVLANプールを管理しています、ここで一つのアプリケーションを持っている場合しかし、あなたは、その時点で、右にあります。なぜそれをやるようなものですか?だから私たちの第二段階は、あまりにも離れて私達の顧客からの抽象化にあります。私たちのポータルは言うのであれば、私たちはこの顧客を作成して行っている、それは彼らがそれを送信する必要がない理由独特のVLANを必要とします。私たちは、彼らのためにそれを行うだけでしょう。アプリケーションは心配する必要はありませんので、だから、IPAM、VLANプールとそれらの作品とのそれらの作品は、再びAnutaの制御のものを置きます。

学んだ教訓:



20:18 We are getting toward the end here, so I want to sort of wrap this up a little bit. Now if you are talking to somebody who is going to take on an NCX platform and an orchestration project along the lines of what you just talked about here. Have you got some lesson that you've learned that maybe you would like to pass on to somebody who is getting into this space?

Mike: Sure, I mean the very first lesson is, the network orchestration is not easy. So if you choose to go out on your own, be prepared. Then after that, really focus on take the time to really look at what you are really trying to build and design. Again we took the service model approach and what we are providing as a service. So it really takes a lot to take that time upfront. And defining your Yang models for your services. Breaking out like what your services are and the dependencies and once you have a clear vision there, it makes development much more quickly. But that's almost like any project you are going to undertake, right. Initial planning really saves a lot in the long run.

21:23 Well, I think the challenge with the orchestration is that there are too many choices. In the sense that you could take it in many different directions. You could model services in different ways, and then a lot of these modelling systems allow you to do things that you've never done before. All of a sudden you start thinking, well, I could do this and I could do this. There is too much flexibility and suddenly you get lost into what was I trying to achieve, rather than actually, this is what I'm doing sort of thing.

確かに、それは我々がここで解決しようとしているものの事前になぜあなたの目標です:午前21時48マイク?私たちは、その上のフォーカスを維持するだけで、間違いなく、解決しようとしています。私たちは、反復アプローチでそれを行うの問題を解決しようとすると、このすべては、右調査するクールになります。だから、我々はこれを行うことができ、我々は、この他の機能を行うことができますか?だから間違いなくそれを追加しますが、あなたのコアに集中。

Anutaチームでの作業の場合:



22:16 So the thing I find interesting about your NCX deployment is that it is very distributed. You've got multiple data centers, multiple sites, very customized in the sense that you are scanning across lots of different hardware devices in the southbound. But the services you are building at the top are reasonably diverse as well. How have you found working with Anuta, Because this could be a really difficult thing? There is an awful lot of elasticity in there. And when you've got a vendor who is like, here is the product, let's you on you alone. That's not what you need.

22:49 Mike: Again when we looked we knew we had two things. If we just wanted a product and we wanted something to work tomorrow, we know that and working with Anuta, we could utilize professional's services and we could get what we wanted. But that doesn't work in an on call arena where I'm getting calls at 3 A.M. and I'm not sure how it works. So it's like, oh, wait I've got to call my vendor. So we made the choice of taking the investment and learning the platform. Now the thing that I loved about the platform is, even though it's an appliance delivered in a VM in somewhat of a black box. It's still really open especially with the SDK; the NDK they call it. And so with that, not only, it's pretty much an open book at that point as far as configuration and how things work. But you still have the ability to expand on devices. Let's say, maybe a fully featured command set was not fully supported right now at this moment, I can go ahead and fix that and I can expand it myself on top of the product that's delivered. And then if it is something really useful I can feed it back to Anuta and they can include it for everyone. Or if there is not a device, say we have our own device and it's not supported by Anuta, I can actually write the templates and things to support that device as well. So we've got a lot of flexibility there. And spending the time and learning the platform and the product will really reap benefits for moving forward and the things we want to do. We don't have to rely on anyone else to move our agenda forward.

要約:



24:31まあ、マイクは私はそれが今日のためにちょうどそれについてだと思います。私がお聞きし、それ以上の質問を持っているとは思いません。お時間をどうもありがとうございましたので、私はそれを本当に感謝しています。あなたは人々があなたを見つけることができるインターネット上のどこにでも持っていますか?あなたはブログか?

マイク:まあTwitterやLinkedInの外、あなたは私を見つけることができます LechnerMike Twitterで、オン リンクトイン そのようなブログか何かではなく、何も。

今日のショーを後援するためにAnutaネットワークに私たちの今日と感謝を結合するための非常24:56まあマイクのおかげ。私は、彼らがNCXプラットフォーム上で何をしているかについて、お客様と少し話しています。今、あなたはpacketpushers.netでそのコミュニティのブログと一緒にこの多くのより細かな無料の技術ポッドキャストを見つけることができます。あなたはTwitterの@packetプッシャー上のパケットプッシャーに従うことができます。 iTunesや他の細かい活動の範囲で私たちを書き、Facebook上で私たちのよう、LinkedInの上で私たちを見つけます。そして、少なくとも最後のではなく、あまりにも多くの技術が十分になることはないことを覚えておいてください。
NCXについての詳細を知ります

タグ