![参考)
踏み台サーバを経由した遠隔サーバのKVMのVMにVNCログインする方法
KVMにWindowsVMをのせたとき、WindowsVMにコンソール(VNC)でログインする方法を記載する
又、遠隔にあるものと想定し、踏み台サーバ経由でログインする事を想定とする
KVM上のVMにVNCログインするベストな方法がわかりました。
①対象VMのvncdisplay内容をメモ（出力例：127.0.0.1:18)
②以下で踏み台サーバから対象VMがのるHVにログイン
ssh (ユーザ名)@(対象KVMサーバ) -L 5900:localhost:5918
③ssh転送で[ローカルポート：5900]、[リモートホスト：127.0.0.1]、[ポート：5900]を設定
④VNCでlocalhost:5900にログイン](https://image.slidesharecdn.com/apchmuraokacloudstudy-191223062110/85/-9-320.jpg)
クラウド構築 勉強会やったのでまとめました
- 3. 勉強会の進め方 1. 課題作成 2. 課題の結果発表 3. 質疑応答 4. 次の課題を講師から提示 5. 次勉強会までに課題に対する資料作成(?体2週間) ?これを繰り返します? ※発表中質問したりするのはOKとします
- 5. BGP Q) CLOS IP Fabric上のUnderlayNWではBGPが使?されているがneighborには何のIPを設定 していますか？ A) 結線されている対向NW機器IFのIP 解説) UnderlayNWではBGPを使?して各NW機器同士にフルメッシュで疎通性を持たせます。 各NW機器同士のIFにIPを設定してBGPを確立させることによって実現します。 Spine(S)Spine(D)Spine(C) LF(C) LF(D)LF(C) LF(D) LF(S)LF(S) 10.4.2.5/30 10.4.2.6/30 10.4.3.5/30 10.4.4.5/30 10.4.3.6/30 10.4.4.6/30
- 7. Q) LeafSWにはControlPlane?ポートが存在するが何に使?するか？理由含め答えよ。 A) 各NW機器を制御するため 解説) クラウドではお客様が使うリソース(SVやST)にアクセスため、OverlayNWを形成してリーチできるようにしてい る。具体的にはリソースの隣接するNW機器(EdgeRouter)にお客様のVLANやVXLAN振って BGP Spine(S)Spine(D)Spine(C) LF(C) LF(D)LF(C) LF(D) LF(S)LF(S) GW SV SV ST VRF VRF VLAN internet
- 9. 参考) 踏み台サーバを経由した遠隔サーバのKVMのVMにVNCログインする方法 KVMにWindowsVMをのせたとき、WindowsVMにコンソール(VNC)でログインする方法を記載する 又、遠隔にあるものと想定し、踏み台サーバ経由でログインする事を想定とする KVM上のVMにVNCログインするベストな方法がわかりました。 ①対象VMのvncdisplay内容をメモ（出力例：127.0.0.1:18) ②以下で踏み台サーバから対象VMがのるHVにログイン ssh (ユーザ名)@(対象KVMサーバ) -L 5900:localhost:5918 ③ssh転送で[ローカルポート：5900]、[リモートホスト：127.0.0.1]、[ポート：5900]を設定 ④VNCでlocalhost:5900にログイン
- 11. Q) Githubに資材をpushしたら、PullReq無しでmasterにマージされてしまいました。なぜで しょうか？ A) branchがmasterの状態で編集してpushしてしまったから 解説） GithubのMasterはプロジェクト内全体で管理しているものなので、通常は「コード修?branch」をcheckoutした上でコードレ ビューをし、管理者やそれ相当の担当者がmasterへのmerge(修正)を行う。 Masterのまま一般作業者が修正を書けてgithubにpushしてしまうと、制限がかけられていない限り、そのままMasterが更新され てしまうため、注意が必要になる。管理者以外でない限り直接masterへpushできないように制限かけるのが一般的である。 前提としてgithubはチーム内で管理するもののため、以下のようにコード修正を行うのが一般的かと思われる ①git pull (or git fetch –all) ＃コード最新化 ②コード編集 ③git diff & git status ＃修正したコードを確認 ④git add . ＃修正したコードpush対象に含める ⑤git status ＃pushするコードの最終確認 ⑥git commit -m “一般的に修正内容がわかるようにコメントを記載” ＃コードのコミット ⑦git push ⑧githubを確認してコミットのpull reqを実施し、チーム内レビューを実施 ⑨管理者側でmergeを実施
- 13. 参考) SQLでのRDB変更について RDBでの変更系DMLコマンド(例えばUPDATE)実施の際には必ず以下流れで実施する事が常識になっている ①SELECTで対象を検索 ②UPDATE or INPUT or DELETEで変更 ③SELECTで対象が変更された事を確認 ④COMMIT;変更確定 またDDL(例えばALTER)と呼ばれるテーブル構造自体に変更を加えるコマンドはCOMMITせず変更が実施されてしまうため注意 が必要。
- 16. Q) CLOS IP FabricにてLeafとSpine間のIPのサブネットはいくつにすれば良いか？ A) /30にし、セグメント節約、無駄なBUM通信をなくす。 解説) CLOS IP Fabric構成では経路広告として「BGP」を使うのが一般的である。iBGPを使う場合と、eBGPを使う場 合があるが、eBGPの方が、間違った経路広告を防げるメリットがあるため、eBGPの方が主流である。 eBGPを使うの場合は対向NW機器側に疎通性があれば良いので、トラフィックを最小限(２)にし且つIP節約のた め、サブネットは「/30」に設定するのが一般的である
- 17. Q) 間違ったgit資材をpushしてしまった場合、どう巻き戻しますか？1つ以上答えよ。 A) git revert ? git pushで巻き戻す(ロールバック)。 解説) シチュエーションとしては間違ったソースコードやパラメータをgithubにpushしてしまった場合どうやって戻す かです。手法として以下２つが考えられると思います。 git reset を使?する手法 git revert を使?する手法
- 18. Q) クラウドにおいてVMとBaremetal(BM)とではEdgeRouterとなるコンポーネントが異なる。 それぞれContrailの何というコンポーネントになるか？ A) VMは同HV上にのっている「Contrail vRouter」がEdgeRouterを担う BMは「対向NW機器(主にQFX)」がEdgeRouterを担う 解説) ここでいう「Contrail vRouter」のことを「SoftwareVTEP」と言いsoftware上のRouterでVXLAN encap、decap をする。それに対して「対向NW機器」のことをHardwareVTEPと呼びHW上でVXLAN encap、decapを行う。 HardwareVTEPに関してはBMサービスだけでなく、StorageサービスやGWサービス等、様々な場面で使われま す。SDN ControllerがNW機器に対応している必要があるため、機器選定には注意が必要です。
- 20. Q) EdgeRouterにてOverlay?論理ポートを設定しないとae(LACP)がUPしないのはなぜか？ A) クラウドで使われるEdgeRouter(HardwareVTEP)はリソースがお客様に使われていない状態だと、対象リソース機器に疎通性が ない状態にしないといけないためNWConfigが言わば「中途半端に入っている状態」だといえる。 中でもaeポート(冗?ポート)をリソース機器につないでいる場合、例えば以下★部分が入っていない状態であるためLACPの定義 はしていてもL2で使うのか？L3で使うのか？を設定していないためポートとしては無効(Down)の状態にある。 ==================================================== ae0 { description ${Description_Name}; flexible-vlan-tagging; ★ VLANタグを使?するための宣言 mtu 9216; encapsulation extended-vlan-bridge; ★ カプセル化を行いVLAN上にてL3上をブリッジングする宣言 aggregated-ether-options { minimum-links 1; local-bias; lacp { active; } } unit 3 { ★ 論理ポートの定義 vlan-id 3; ★ VLANidの定義 } } ==================================================== ★のコンフィグはすべてお客様のLN毎に割り当てられるVLAN(L2)の話です。つまりこのようなOverlayコンフィグが投入される と、aeポートをL2ポートとして定義するため、ポートがUPするという訳です。
- 22. Q) Openstack DNSaaSのようにパブリックDNSレコードの処理フロー(作成?更新?削除)を 説明せよ。 A) ①DNSaaSではお客様がどこの拠点で作成しても、同じテナントであればレコードを引けるようにする必要があります。 東京拠点 US拠点 Keystone EU拠点 Keystone Keystone DNSサーバ DNSサーバ DNSサーバ ポータル インターネット DNSコント ローラ
- 26. Q) GW(MX80)からお客様SOの経路を調べたい場合はどうするか？ A) 以下のようにvrf(instance)を指定してする。BGPなども同様である。 ============================================= hoge@vpgw0001> show route instance vrf_gw_1025 Instance Type Primary RIB Active/holddown/hidden vrf_gw_1025 virtual-router vrf_gw_1025.inet.0 4/0/0 vrf_gw_1025.inet6.0 1/0/0 hoge@vpgw0001> ============================================
- 27. Q) QFX同士でOverlayNWの疎通性を確認したい場合はどうするか？ A) Contrailを使ったOverlayNWの疎通性を見たい場合、vRouter-vRouterとQFX-QFXの2通りのCaseがあります。 ※ただしvRouter-QFX間の疎通確認は未確認 ? vRouter-vRouterの場合 ①ContrailのGUIにアクセスする。 ②左側の、Monitor -> Infrastructure -> vRoutersをクリック。送信元としたいvRouter １台を選ぶ。 ③ Introspectの画面 (Modules for contrail-vrouter-agent)で、「diag.xml」をクリック。 ④ "Diag Introspect"の画面が出て来るので、PingReqの中に検査対象の情報を投入し、「Send」をクリック。 必須項目は、source_ip、dest_ip、protocol、vrf_name (string) ⑤実施結果を確認する。 ? QFX-QFXの場合 送信元QFXから以下コマンドを実行（traceroute overlayも存在します） ping overlay vni ${vni} tunnel-src ${source-vtep} tunnel-dst ${dest-vtep} ※必須引数のみ
- 29. Q) CLOS構成のクラウド環境においてVMサービス(Openstack Nova)に使われるHVへのOSイ ンストールをする際、カスタムISOを使?してPXE BootでOSインストールを行うが、PXE BootでOSインストールが可能な理由を答えよ。 A) まず問題の意図を理解する必要があるため、?語を整理していく PXE Boot： NW bootの事で、対象サーバに遠隔からOSをインストールをする。OSインストール直前の段階でDHCPにてIPを振る必要がある。 カスタムISO： CentOSでいうKickstartのことでOSインストールと同時にOS設定やpkgインストールを自動化するときに使う。 CLOS構成でのNWはBGPでのL3経路広告を実施している。OpenstackController、その他管理サーバとComputeはそのBGPを隔 てた位置にあり、通常L3通信が必要になる。しかしComputeを追加する際にOSをインストールするにはPXE Bootにて管理サーバ からDHCPのL2通信が必要になる。これを解決するためCisco IOSやJuniper JUNOSを搭載したNW機器には「IRBというブリッジ ング機能」を使って、特定のサブインターフェースのみ「L2 on L3通信」を可能にする仕組みを?いている。 BGP(L3) Spine(S)Spine(D)Spine(C) LF(C) LF(D)LF(C) LF(D) LF(S)LF(S)DHCP(L2)
- 30. 実際に経由するL3SWのQFXとadminGW(MX)を見てみます。(VDXはL2SW) edge-sw0001> set interfaces ae0 description edge-cp0001n_LAG set interfaces ae0 native-vlan-id 205 set interfaces ae0 mtu 9216 set interfaces ae0 aggregated-ether-options minimum-links 1 set interfaces ae0 aggregated-ether-options local-bias set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN201 Set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN202 set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN203 set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN204 set interfaces irb unit 201 family inet address 10.0.11.1/26 set interfaces irb unit 202 family inet address 10.0.12.1/26 set interfaces irb unit 203 family inet address 10.0.13.1/26 set interfaces irb unit 204 family inet address 10.0.14.1/26 set vlans VLAN201 vlan-id 201 set vlans VLAN201 l3-interface irb.201 set vlans VLAN201 domain-type bridge set vlans VLAN202 vlan-id 202 set vlans VLAN202 l3-interface irb.202 set vlans VLAN202 domain-type bridge set vlans VLAN203 vlan-id 203 set vlans VLAN203 l3-interface irb.203 set vlans VLAN203 domain-type bridge set vlans VLAN204 vlan-id 204 set vlans VLAN204 l3-interface irb.204 set vlans VLAN204 domain-type bridge ?次ページに続きます? L2(ブリッジング) ae0ポートに複数のVLANを割り当て irbに各vlan毎のサブIFを設定しGWIPを設定する 各VLANにirbのサブIFを割り当て、 ブリッジ設定(L2)にする ae0.201 ae0.202 ae0.203 ae0.204 irb.201 10.0.11.1/26 irb.202 10.0.12.1/26 irb203 10.0.13.1/26 irb.204 10.0.14.1/26 L3(BGP) L3(BGP) irb.3001 10.1.0.1/28
- 31. admin-sw0001> set interfaces ae0 description admin-sv0001_po1 set interfaces ae0 mtu 9216 set interfaces ae0 aggregated-ether-options minimum-links 1 set interfaces ae0 aggregated-ether-options local-bias set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN3001 set interfaces irb unit 3001 family inet filter output BUM-FILTER set interfaces irb unit 3001 family inet address 10.1.0.1/28 set vlans VLAN3001 vlan-id 3001 set vlans VLAN3001 l3-interface irb.3001 set vlans VLAN3001 domain-type bridge irbは図の通りL3上の通信をL2化(いわゆるブリッジ)したい場合に使います L2(ブリッジング) ae0.201 ae0.202 ae0.203 ae0.204 irb.201 10.0.11.1/26 irb.202 10.0.12.1/26 irb203 10.0.13.1/26 irb.204 10.0.14.1/26 L3(BGP) L3(BGP) irb.3001 10.1.0.1/28 ae0.3001
- 34. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー① 34 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BM Controller Contrail ※BMリソースにはOSは入っていない フロント側からBM ControllerへBMのSOが入 る QFX Leaf 2 L2SW L2SW BMリソース 表 裏
- 35. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー② 35 QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail BM ControllerからBMリソースのIPMI にて電源投入(再起動)を実施し、pxe boot可能な状態(DHCP Discover)にする QFX Leaf 2 L2SW L2SW BMリソース 表 裏
- 36. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー③ 36 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail BMControllerからContrailへオーバーレイNW 作成に必要なAPIが入力される QFX Leaf 2 L2SW L2SW BMリソース 表 裏
- 37. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー④ 37 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail ContrailからQFXにオーバーレイ?のConfigを 転送する。 これによりBM ControllerからBMリソースへ のL2での専?経路(オーバーレイ)が作成され る QFX Leaf 2 L2SW L2SW BMリソース 表 裏 config
- 38. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー⑤ 38 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail DHCP DISCOVERがControllerに届くよう になりpxe bootが開始される QFX Leaf 2 L2SW L2SW BMリソース 表 裏 DHCP DISCOVER
- 39. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー⑥ 39 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail pxe bootによりIP割り当てを含んだ「初期 RAMディスク」がBMリソースに転送され る 初期RAMディスクはカーネルの一部として 動くシステムファイルで、OSなしでIPを割 り当てるのに必要です QFX Leaf 2 L2SW L2SW BMリソース 表 裏 初期RAMディスク
- 40. Copyright ? APCommunications Corporation. All right reserved. Baremetal SO時のフロー⑦ 40 MX QFX Leaf 1 QFX Leaf 3 QFX Spine BMController Contrail QFX Leaf 2 L2SW L2SW BMリソース 表 裏 Openstack Glance QFX Spine QFX Leaf 3 BM ControllerからAPIにてGlanceに必要なOSを 要求 Storageプレーンから必要なOSがBMリソースに インストールされ、最後再起動を実施する
- 47. Q) VPNのSOが入るとコンフィグがVPGWに転送される。どのようなコンフィグか3つ以上答 えよ。 A) 1. VPN?のVLAN、サブIFの設定 2. VPN?VRFの作成 3. VPN?のIP設定(uplinkとdownlink) 解説) VPNにてテナントが自PCとつなぐためには、主に以下のような設定が必要です。 1. ローカルPCのVPN設定 2. VPN?GWのVPN設定(uplink) 3. VPN?GWからクラウド環境側にルーティングするための設定(downlink)
- 48. Q) ContrailにおいてConfigNode/ControllerNode/AnalyticsDBNode/AnalyticsNode/TSNNode の役割を説明せよ。 A) ConfigNode： ESIからのAPIを受けてControllerにdevice、port情報を転送する ControllerNode： Compute上のvRouterやTSN上のvRouterとの経路交換を担当する。 SOはConfigNodeからのAPIをもとにNWConfigレベルに整理される。 AnalyticsNode： 各統計情報を収集する。最悪なくてもSDNとしては動く。 AnalyticsDBNode： 各統計情報や経路情報を格納するDBノード。Cassandraを使?している。 TSN： ToR Service Nodeの略。QFXを管理?制御するNodeで、ToR-Agentというプロセス情報をもとに QFXへのConfig(オーバレイNW)連携や正常性確認を行う。Config連携にはOVSDBを使っている。
- 50. Q) Contrail R5.1-EVPNを導入する際のポート定義の変更点を説明せよ。 A) EVPNの影響を受けるのは、実際にプロトコルを使?するdeviceとportである。 そのため考慮点は以下の通りとなる。 ? OVSDB方式ではMC-LAGを組んでいたため、physical-routerにcluster名だけを指定していましたが、 EVPN方式ではMC-LAGを組まないため物理両系deviceの登録が必要になる。 ? EVPN方式ではphysical-interfaceにvirtual-machine-interfaceという対向毎のIFを定義する。 それをvirtual-port-groupsという単位で定義することによってその中で冗?化を実現させます。 参考情報) https://www.juniper.net/documentation/en_US/contrail5.1/topics/concept/contrail-virtual-port-groups.html SV-BSV-A MAC virtual-machine-interface (physical-interface) virtual-port-group
- 51. ■OVSDBの場合 VitrualChassis(VC)が組まれた1C単位で制御?管理。冗?性をVCに依存してしまっている。 SV-BSV-A label label MAC(arp) MAC(arp) SV-BSV-A VC VC ■EVPNの場合 各NW機器で制御?管理。冗?性は各NW機器で担保。 MAC(arp) MAC(arp) label label physical-router physical-router physical-router physical-router physical-router physical-router