[VMware] VMware Cloud Foundationに挑んだが負けた

Tanzuを動かす前提条件として

VMware Cloud Foundation(略してVCF)は、所謂「プライベートクラウドを自動構成する」機能でありまして、VMware上の機能をフル活用していろんな機能を実装します。特にVMware NSX-T Datacenterの機能を駆使してSDN(?)的なものが構成できるというのが大きな特徴のように思えます。

vSphere7.0から、Tanzuと呼ばれるKubernetesエンジンを稼働可能なコンテナインフラストラクチャを組むことが出来るようになりました。が、このTanzuを利用するには、その環境内にワークロード管理ライセンスを包括したESXiライセンスが必要で、どうやらこのライセンスを適用するにはVCFを構成した上での環境が必要そうです。

実際にお仕事で使うのかどうかはさておき、知っておくには越したことはないなということで、VCF環境の組み立てに挑みました。
しかしながらどうにも前提情報が無く、苦労したので備忘録として情報を残す次第です。取り扱う内容としては

  • VCFを組む前提構成とは?
  • VCFを組む上ではまったポイントは?

と言うところが述べられたらなと思ってます。

後述しますが、結果的にVCF環境を構成することは出来ませんでした。この辺りも合わせて述べたいと思います。

Read more

[20190626][Cloud][Network] Azure Networkの動きを追いかけてみるなど

IaaSにおけるルーティング Microsoft Azure のIaaS環境におけるルーティングとして、オンプレミスと比較すると実はあまり設定箇所がない。強いて挙げるなら * UDR(User Defined Route:リソースはルートテーブル)による静的ルート設定 * VPN GatewayやVNET間のピアリングによる経路広報 * Service Endpoint設定による、特定SaaS/PaaSに対する経路広報 ぐらいなのかな。そこにIGPなんかは気持ちいいぐらい入ってこない。 こうした設定の結果、VMなどにはどういう経路が広報されているのかを知ることが出来る。「有効なルート」と言う設定で、例えば以下のようなことが確認できる。 有効なルートで見えるもの システムルート どんなVMやIaaSコンポーネントにも採用されるデフォルトのルーティング設定であり、具体的な内容としては * デフォルトルートはインターネットへ向いている * プライベートアドレスに関しては、原則ブラックホール行き * CGN用プレフィックスも基本的にはブラックホール行き * 同一VNET間の通信はVNETを伝わってどこにでも行ける(仮想ネットワーク) というのが書かれている。優先度は低く、カスタムルートなどで指定されていない場合はこのルートが原則採用される。 動的ルート VPN GatewayやVNET Gateway(Express Route Gateway)、VNET Peeringによって広報される経路が適用される。その機能名などから恐らくBGPが使用されてるんだろうなーと思われるんだけど、詳細はわからない。 なお、Service Endpointなどの定義によって定められるルーティングに関しても、この動的ルートのカテゴリに含まれる。 User Defined Route(UDRまたはカスタムルート) ユーザが「ルートテーブル」リソースを使用して定義するカスタムルーティングテーブルを指す。UDRは「カスタム定義ルート」の列に定義したルートテーブルリソース名が付与される。 ルートの反映 ルートの反映を行うにあたり、その優先度は以下のようになる。 * ルーティングの大原則(ロンゲストマッチ等)にまずは従う * 情報の優先度は「カスタムルート>動的ルート>システムルート」 VNETを少しだけ紐解いてみる サーバ側のコマンド結果から、こうではないかと。 まず、VNET内のサブネット上のサーバにIPアドレスを動的で付与すると、かならず第4オクテット4から順にIPアドレスが払い出される。サーバ側でip rコマンドを打ってみると、上図のように第4オクテット1のアドレスがデフォルトゲートウェイとして定められている。 どうやらこれがVNET単位で配置されている、隠れたL3デバイスのようだ。そしてarpテーブルを覗いてみると、面白いMACアドレスがゲートウェイに対して割り当てられてるのが見受けられる。 12:34:56:78:9a:bc なんだこれわ。こんなのみたことねぇ、ってか恐らくはソフトウェアが払い出してるMACアドレスなんだろうなーと言うのは容易に想像がつく。この時点でAzureのネットワークは何かしらSDN(Software Defined … Read more

[Mail][Office365][Cloud] メール基盤のクラウド化

グループウェアを変更して間もないんだけど

過去、メール基盤に手を加えるという記事の中で、WebメールをZimbra Community EditionというOSSグループウェアに切り替えたのですが、ここ最近仕事上でもこの手のサービスのクラウド化とかが耳に聞こえたりすることが多く、ちょうど私自身Office365 for Businessを触っていることから、ついでにExchange Onlineなるものを触ってみようかということで手を出しました。

Read more

[Virtualization][Linux][k8s] Project Calicoの設定を変更する

近況報告

ちょい前辺りから、こんな風にコンテナ環境を組んでいるわけですが

あれからいろいろ増強しまして、

  • ESXiサーバを1台追加(PRIMERGY TX120 S3を増設)
    • Core2Duo P8700x1(1P/2C)/ 8GB RAM/ 146GB SAS x2(RAID1)
  • Cephを構築
    • 4ノード構成
      • 1号機:NAS上のデータストアで構築(ESXi#2を使用)
      • 2号機:ローカルデータストアで構築(ESXi#1を使用)
      • 3号機:NexentaStorの重複排除データストアで構築(ESXi#2を使用)
      • 4号機:ローカルデータストアで構築(ESXi#3を使用)
  • Workerノードを増設
    • ESXi#3に増設。結果、全体として1Master/5Worker構成に

となりました。成長したなぁ、知らないうちに。

Read more

[Network] BGP4+設定を見つめ直す

先の記事でも書いたことなのですが

JANOG41に出席したことのまとめ記事にも書いたように、結構私ネットワーク方面の無知っぷりを痛感するケースが幾つかあり、特に動的ルーティングに関する知識は本当にないんだなぁ・・・と、ある意味独学の限界(私の技術力の限界とも言う)みたいなものを感じております。

特に響いたのは以下2点、それを受けて色々考えさせられました。

  • 経路は極力まとめて広告するものだよ(Aggregateすべきだと言ってました)
    • 私個人的には、経路は細かく広告するのが良いと考えていました。
    • 冷静に考えてみると、確かに経路が多いことはリソースの無駄な消費につながる上、経路変更が頻発した場合その影響がAS間となると、全世界のルーターに影響が及びますもんね・・・
    • IPv4はクラスレスの概念が入って細かい経路がガンガン作られたことも有り、かなりの経路数があるけど、そう言えばIPv6はちゃんと経路がAggregateされていて、5万経路ぐらいで全体を回れるようになってるなぁ・・・とかおもったなど。
  • ルーティングループはゼッタイ起こしちゃダメだよ
    • 確かにループさせるとその経路間パケットはTTLが尽きるまでぐるぐる回ってしまうので、下手すると帯域輻輳につながるんだなあ・・・
    • でも、未定義のセグメントに対して通信来た場合どのようにガードするんだろう?

で、ウチの場合だと間違いなく危ないのがIHANetの経路で、非トランジットなのが幸いして影響範囲は狭いのですが、細かい経路広告を行ってしまっていて、あー、これはピアつなぐ人によってはうんざりされてしまうかもしれないなぁと思い、設定修正を考えることにしました。

Read more

PAGE TOP