Hero Image
nfsstatコマンドで出力される項目の理解の仕方

RC : Reply Cache FH: File Handles stale file handles NFS クライアントが開いたファイルまたはディレクトリが、サーバー上で削除されたかまたは置き換えられました。 IO: Input Output ディスクから読み取ったバイトの総量と、ディスクに書き出したバイトの総量 TH: Threads NFSプロセスのスレッドの情報 Threads NFSデーモンによって使用されているスレッドの数 fullcnt すべてのNFSスレッドが利用された総数 RA: Read Ahead Cache Read ahead cache 連続したブロックのリクエストが予想されるときに使用されるキャッシュである。あるブロックの読み出しが要求された時、そのブロックの次のブロックが読み出される可能性が高い。そのため、NFSのスレッドはこれらの次のブロックをキャッシュする。 cache size 大抵スレッド数の2倍 10%-100% ブロックが見つかった深さの度数分布 not found read-ahead cacheになかった回数 NET: Network ネットワークの使用率統計 netcount 全てのパケットの数 UDPcount 全てのUDPパケット数 TCPcount 全てのTCPパケット数 TCPconnect 全てのTCPコネクションの数 RPC: remote procedure call NFSは、クライアントとサーバの間のリクエストを道づけるためにRPCに依存する rpccount 全てのRPCの命令 badcnt badfmt badauth badclnt の総数 badfmt ほとんどのbad call badauth 認証ミス badcInt 使用されず Proc2 Proc 2 v2プロトコルを使用するNFSクライアントの状態。これはかなり古く、(1989年)v3やv4でなくv2を使う十分な理由は見つからない。 操作はv3プロトコルとほとんど変わらない

Hero Image
NSX-TのTransport Zone、Overlay, VLANトランスポートゾーンはどう違うのか?

本記事に関して vCD(VMware coud Director)の利用に向けて、NSX-Tを利用した検証を実施しているが、その際にNSX-T周りの用語で少し戸惑ったので、メモとしてこちらに残すことにした。 VMware HOL(Hands on Lab)での説明は下記 私には理解できなかったので、以下で説明する。 NSX-T Transport Zoneとは トランスポートゾーンは、論理スイッチを作成するノード(ハイパーバイザーとNSX Edge)の通信可能な範囲を定義する。トランスポートゾーンの範囲に含まれるノードにはそのトランスポートゾーンに対応したN-VDS(次で説明)が作成され、それによりVMがNSX-Tの論理ネットワークに接続できる。 Overlay Transport Zone とVLAN Transport Zoneの2種類がある。これらの違いについては後で述べる NSX-T Data Center Virtual Distributed Switch (N-VDS)とは NSX-T専用の特別な分散仮想スイッチと考えれば良く、トランスポートゾーンに所属するノードに作成される。NSX-Tの論理スイッチ上の通信がホスト間で転送される際のカプセル化のエンドポイントや、論理ルータのアップリンクとなるポイントである。 イメージとしては下記のような図になる Overlay Transport Zone とVLAN Transport Zoneは何が違うのか? イメージ図をご覧いただいた方が理解が早いかもしれません。 両者の違い それぞれ、仮想マシン間の水平方向の通信と、NSX-Tのネットワークと物理ネットワーク間の垂直方向の通信を処理する役割を担っている。オーバーレイトランスポートゾーンはNSX-vのトランスポートゾーンと近いが、ハイパーバイザーだけでなくNSX Edgeも追加する点が異なる。VLANトランスポートゾーンはNSX-vではなかった要素となり、NSX Edgeのみが追加される。 最後に 今回の記事では、NSX-TのTransport Zoneとは、Overlay・VLANトランスポートゾーンの違いは何なのか? について解説しました。何かコメントなどあれば下のチャット欄からお願いします。

Hero Image
NSX-Tを利用したL2 オーバレイNWに関して解説する

NSX-TのL2オーバレイネットワークについて 今までのvSphereでは、分散スイッチに分散ポートグループを追加した時、分散スイッチが展開されているESXiホストを収容する物理スイッチ側にも設定変更が必要であった。 もし、ESXiホストはサーバチーム、物理スイッチはネットワークチームが管理している場合、サーバチーム側のESXiホストの設定変更が完了しても、ネットワークチーム側の作業が完了するまで、新規追加した仮想マシンは外部と通信できないという問題があった。(下図) また、従来のvSphereは、VLANのみのサポートであった。そのため、離れたESXi間に跨るL2ネットワークを構築できないという課題があった。(下図) NSX-Tを使用することで、物理ネットワークの設定変更無し、かつ、物理ネットワークの構成を意識せずに、離れたESXiホスト間に跨るL2オーバレイネットワークを構築可能になる。 NSX-VではL2オーバレイネットワークの構築にVXLANを使用していたが、NSX-TではVXLANの機能を拡張したGeneve(Generic Network Virtualization Encapsulation)を利用する。 NSX-Tのバージョン 2.5以前では、オーバレイネットワークを構築するには、NSX-Tの機能を保持した専用の仮想スイッチであるN-VDS(NSX-T Virtual Distributed Switch)が必要だった。一方、バージョン 3.0からは従来の分散スイッチをNSX-T用の仮想スイッチとしても使用可能になっている(NSX-Vと同じパターン)。 N-VDSには、Geneveによるパケットのカプセル化を実施するTEP(Tunnel End Point)が生成される。TEPの実体はVMKernel Portである。 仮想マシンが接続するN-VDSのポートグループの事を、Logical Switch、または、Segmentと呼ぶ(以降はSegmentと表記)。このSegmentに対して、L2オーバレイネットワークの識別子であるVNI(VXLAN Network Identifier)が割り当てられる。 また、N-VDSやvDSに接続する仮想マシンのvNICのことをVIF(Virtual Interface)、VIFの接続先のN-VDSやvDSのポートのことをLIF(Logical Interface)と呼ぶ。 NSX-TのGeneveを使用したオーバレイネットワークでは複雑な通信が発生しているように感じる方もいられると思う。しかし、物理ネットワーク側の観点から見ると、NSX-Tのオーバレイの通信は、従来のESXiホストのVMKerne間の通信と同じである。そのため、物理ネットワーク側ではTEP用のVMKernel Portの収容しているポートグループに対応するVLANを作成し、MTUを調整し、TEP間で通信できるようにルーティングを設定するだけである。 Transport ZoneとTransport Nodeについて 詳しくは、前記事を参照。 本記事でも一応少し説明する。 NSX-TにはTransport Zoneと呼ばれるものが存在する。(Transport ZoneにはGeneveとVLANの2種類のタイプが存在するが、本記事では都合のためGeneveタイプのTransport Zoneを基に解説します。) Transport ZoneはL2オーバレイネットワークを展開する範囲を制限するためのコンポーネントで、SegmentやESXiホスト等に関連付けられる。 ESXiホストは自身が所属しているTransport Zoneと同じものが割り当てられたSegmentのみ認識可能。つまり、ESXiホストは自身が所属いしてるTransport Zoneと同じものが割り当てられたSegmentに対してのみ、仮想マシンのvNICを接続可能となる。 ESXiホストはTransport Zoneに参加することで、NSX-Tのオーバレイネットワークを構築可能で、Transport Zoneに参加しているESXiホスト等のノードのことをTransport Nodeと呼ぶ。 NSX-VではCluster単位でTransport Zoneを割り当てる必要があった。一方、NSX-TではESXiホスト単位、Cluster単位でTransport Zoneを割り当て可能。 Cluster単位でTransport Zoneを割り当てる場合、最初にTransport Node Profileを使用して各ESXiホストに適用する共通の設定を定義する。その後、Clusterに対してTransport Node Profileを割り当て、Clusterに属する全ESXiホストがTransport Zoneに参加する。 Uplink Profileについて Uplink Profileでは、ESXiホスト内に生成されるN-VDSのUplink Portの数やチーミング方式(Active-Standby、Active-Active、LAG)を定義するためのコンポーネントである。 N-VDSのUplink PortとESXiホストのvmnicのマッピングはTransport Node Profile等で設定する。

Hero Image
SquidでProxyサーバを構築する

CentOSでプロキシサーバを構築する 背景 業務でインターネット接続ができないサーバから、インターネットに接続できるサーバをproxyとして外部NWと通信する必要があった。今後も似たようなことは多いと思われるのでこちらにまとめる。 Proxyとして動作させるサーバへSquidをセットアップする yumでインストールを行う sudo yum update sudo yum install squid バージョンを確認して正常にインストール出来ていることを確認する。 squid -v Squidの自動起動設定を行い、再起動する。 sudo systemctl enable squid sudo systemctl restart squid 4.Squidがポート3128を使用していることを確認する。 sudo lsof -i:3128 5.出力例 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME squid 21800 squid 11u IPv6 37157 0t0 TCP *:squid (LISTEN) 6.firewallの穴あけ デフォルトではSquidのポートは3128が設定されており、Port番号3128へ送られるパケットは受け取れるように設定する。 sudo firewall-cmd --zone=public --permanent --add-port=3128/tcp #許可ポートの追加 sudo firewall-cmd --reload #設定反映 sudo firewall-cmd --zone=public --list-all #結果確認(portに3128が追加されていることを確認) proxy clientへのセットアップ proxyを踏み台にプライベートIPでclientにSSHする。 それぞれの設定ファイルにプロキシの設定を記入する。