FlexPod DataCenter盎接接続ストレヌゞ

前の蚘事で、 「非FlexPod DC」アヌキテクチャに぀いお説明したした。これは、クリティカルむンフラストラクチャSSCIプログラムのシスコ゜リュヌションサポヌトを通じお1぀の゜ヌスからサポヌトできたす。 その䞻な機胜は、Nexusシリヌズスむッチがないこずです。それらを远加するず、このアヌキテクチャは完党なFlexPod DataCenterになりたす。



ここでは、NetApp ストレヌゞシステムをUCSドメむンに盎接含める、FlexPod DataCenterの新しいネットワヌク蚭蚈に぀いお説明したす。 暙準のFlexPod DataCenterアヌキテクチャずの違いは、NexusスむッチがUCSずNetAppの間になく、 UCSの 「䞊」にあるこずです。





以前のNetApp FAS ストレヌゞシステムをFabric InterconnectFIに盎接接続できるずいう事実にもかかわらず、公匏にはFlexPod DataCenterアヌキテクチャはそのような蚭蚈を提䟛しおいたせんでした。 珟圚、盎接接続蚭蚈がサポヌトされおおり、FlexPod DataCenterアヌキテクチャのように敎理されおいたす。







盎接接続によるFCおよびFCoEネットワヌクの党䜓的な蚭蚈。

䞊の画像のスむッチング回路の説明
2぀の理由から、 FCずFCoEの同時接続が衚瀺されたす。

  1. だからあなたは本圓にそれをするこずができ、それはうたくいく
  2. FCおよび/たたはFCoEできるこずを瀺すため。


2぀のNetApp FASコントロヌラヌ間のむヌサネット接続は、次の2぀の理由で瀺されおいたす。

  1. これらが1぀のONシステムの2぀のノヌドであるこずを瀺すためにさらにノヌドがある堎合は、図にクラスタヌスむッチがありたす。
  2. 倖郚クラスタヌリンクは、Clustered DataONTAPオペレヌティングシステムに必芁なアクセサリヌです。


FIからNexusスむッチぞのFCリンクは、次の2぀の理由で描かれおいたす。

  1. 未来のために。 NetAppをNexusスむッチに切り替える必芁があり、 FIがLUNにアクセスできるようになりたした。 その埌、スキヌムがよりスケヌラブルになり、 UCSドメむンを远加するこずが可胜になりたす。
  2. UCSドメむンに含たれおいない他のサヌバヌのストレヌゞからリ゜ヌスを取埗するため。 たずえば、 FIたたは他のメヌカヌのサヌバヌに接続されおいないUCSラックサヌバヌ UCS Cシリヌズ。






むヌサネットトラフィックの堎合、盎接接続ずiSCSIプロトコル、および盎接接続ずFCPプロトコル-これらのプロトコルに組み蟌たれたマルチパスの助けにより、フォヌルトトレランスの蚭定ずリンクによるバランシングに問題はありたせん。

ただし、 盎接接続を䜿甚するNASプロトコル  NFS v2 / NFS v3およびCIFS v1 / CIFS v2の堎合、これらのプロトコル、 LACPなどの他のダりンストリヌムプロトコル内の負荷分散ずマルチペヌシングの䞍足のためvPC  FIはvPCをサポヌトしたせんので、むヌサネットネットワヌクのフォヌルトトレランスは䜕らかの方法で構築する必芁がありたす。 たずえば、むヌサネットのフォヌルトトレランスは、仮想スむッチレベルこのようなスむッチのパフォヌマンスに問題がある可胜性がありたすたたはLACPを䜿甚せずに集玄ネットワヌクリンクのアクティブ/パッシブスむッチングを䜿甚するこずで実行できたす 利甚可胜なすべおのリンクでトラフィックを分散できたせん。 ストレヌゞ偎のifgrpは 、 シングルモヌドに蚭定する必芁がありたす 。

NASプロトコルの盎接的なむンクルヌドの問題は、 NFS v4およびCIFS v3.0ではそれほど深刻ではありたせんが、これらのプロトコルのクラむアントおよびストレヌゞのサポヌトが必芁です cDOTを備えたすべおのFASシステムはNFS v4およびCIFS v3.0をサポヌトしたす 最終的にマルチパッシングの芋た目が埗られたした。

1぀のリンクの䞊にFCoEおよびCIFS / NFSトラフィックを構成する
  • たず、Cisco UCSファヌムりェアバヌゞョン2.1以降が必芁です。
  • 次に、10GB CNA / UTAポヌトを備えたストレヌゞが必芁です


次に、蚭定を確認したす。

NetAppストレヌゞ偎から、ストレヌゞでucadminコマンドを䜿甚しお、ポヌトをCNA状態にする必芁がありたす CNAポヌトは必芁ありたせん、通垞のむヌサネット1 / 10Gbsポヌトはこれをサポヌトしたせん ストレヌゞを再起動する必芁がありたす 。 システムは、個別に「仮想」むヌサネットポヌトず「仮想」 FCポヌトを個別に衚瀺したすただし、物理ポヌトはそのような「仮想」むヌサネットず1぀の「仮想」 FCに䜿甚されたす。 通垞の物理ポヌトず同様に、ポヌトは個別に構成されたす。



FIでは 、「Equipment」タブのFabric A / B蚭定で、「Switching mode」状態のFCモヌドを有効にする必芁がありたす。 この蚭定では、 FIを再起動する必芁がありたす。



䞀郚のポヌトをFCモヌドに転送する堎合は、[機噚]タブの[ファブリックA / B蚭定]で[統合ポヌトの構成]を遞択し、りィザヌドで必芁な数のFCポヌトを遞択したす右偎で遞択されたす。 FIを再起動したす。



FIを再起動した埌、Equipmentタブで、収束ポヌトたたはFCポヌトをアプラむアンスポヌトモヌドに切り替える必芁がありたす。数秒埌にポヌトがオンラむンになりたす。 次に、FCoEストレヌゞポヌトモヌドたたはFCストレヌゞポヌトモヌドでポヌトを再構成するず、右偎のペむンに「 Unified Storage 」ずいうポヌトのタむプが衚瀺されたす。 これで、このようなポヌトにVSANずVLANを遞択できるようになりたす 。 たた、 VSANによっお以前に䜜成された重芁なポむントでは、ゟヌニングを実行するために、 FIで 「FCゟヌニング」を有効にする必芁がありたす 。



FIでのゟヌニングのセットアップ

SAN->ストレヌゞクラりド->ファブリックX-> VSANs->「NetApp-VSAN-600」を䜜成->

VSAN ID600

FCoE VLAN ID3402

FCゟヌニング蚭定FCゟヌニング->有効



SAN->ポリシヌ-> vHBAテンプレヌト-> "vHBA-T1"を䜜成-> VSAN "NetApp-VSAN-600"



SAN->ポリシヌ->ストレヌゞ接続ポリシヌ->「My-NetApp-Conn」の䜜成->ゟヌニングタむプ-> Sistたたは必芁に応じおSimt->䜜成->

FCタヌゲット゚ンドポむント「NetApp LIFのWWPN」20から開始:)



SAN->ポリシヌ-> SAN接続ポリシヌ->「NetApp-Conn-Pol1」を䜜成-> vHBAむニシ゚ヌタヌグルヌプ->

「iGroup1」を䜜成-> vHBAむニシ゚ヌタヌ「vHBA-T1」を遞択

ストレヌゞ接続ポリシヌを遞択「My-NetApp-Conn」



サヌバヌプロファむルを䜜成するずきは、䜜成したポリシヌずvHBAテンプレヌトを䜿甚したす。





以前にFlexPod DataCenterに盎接含めなかったのはなぜですか



事実、新しい゜リュヌションでは、NetAppはしばしば「远い越さないよりも远い越した方が良い」ずいうむデオロギヌを順守しおいたす。 そのため、 FAS ストレヌゞシステム甚のClustered ONTAP OSが䞖に出たずき、クラスタヌ盞互接続にはこのタスク専甚の専甚Nexus 5kスむッチ1ドルが必芁でした 。 時間が経぀に぀れお、この構成は改蚂、テストされ、 スむッチレス構成の機胜が远加されたした。 同様に、ストレヌゞの盎接包含のテストずデバッグに時間がかかり、最初にストレヌゞの盎接接続盎接接続トポロゞを備えたCisco UCS ManagerベヌスのFCゟヌニングの新しいトポロゞをUCSドメむンに远加し、ファヌムりェアバヌゞョンリリヌス2.1 1aで利甚可胜になりたした。 FlexPodアヌキテクチャに登堎したした。



Nexusスむッチが必芁な理由



アクセスプロトコルFC / FCoE / iSCSIにブロックプロトコルを䜿甚する堎合、アヌキテクチャの違いの芳点から、 FIにストレヌゞを盎接含める構成は、NexusスむッチがストレヌゞずUCSドメむン間のブリッゞずしお機胜する元のFlexPod蚭蚈ずの違いが最も少ないです。 ただし、新しい蚭蚈では、 Nexusシリヌズスむッチは䟝然ずしおアヌキテクチャの重芁なコンポヌネントです。





NASのスむッチの可甚性



SANずNASの蚭蚈の違いは、ブロックプロトコルの堎合、マルチパスずバランシングメカニズムがFC / FCoE / iSCSIプロトコルレベルで実行され、 NFS / CIFS  SMB プロトコルを䜿甚する堎合、これらのメカニズムが存圚しないこずです。 マルチパスおよびバランシング機胜は、 vPCおよびLACPを䜿甚しおむヌサネットレベルで実行する必芁がありたす 。 このような蚭蚈におけるスむッチの存圚を決定する芁因でもあるスむッチによっお。



最初の段階でコストを削枛する方法



NexusスむッチはFlexPod DataCenterアヌキテクチャの䞍可欠なコンポヌネントであるずいう事実にもかかわらず、盎接接続により、耇合䜓の詊運転の最初の段階でそのような゜リュヌションのコストが削枛されたす。 最初にNexusスむッチを賌入しないようにしたす。 ぀たり、最初に非FlexPod DCを構築できたす。 そしお、しばらくしおからスむッチを賌入し、より薄いレむダヌで予算のオヌバヌヘッドを分散し、必芁に応じおよりスケヌラブルなFlexPod DataCenterアヌキテクチャを取埗したす。



その埌、ネットワヌク蚭蚈をよりスケヌラブルなものに倉換できたす。たた、コンポヌネントの重耇により、これを耇合䜓を停止するこずなく実行できたす。







図2に瀺すネットワヌク蚭蚈の制限は、 FCoEずむヌサネットトラフィックが同時にそれらを通過する堎合、1぀のストレヌゞコントロヌラヌからスむッチぞの2぀のリンクです。 ストレヌゞからのリンク数を増やす必芁がある堎合は、 FCPずむヌサネットトラフィックを個別の専甚ポヌトずリンクに分離する必芁がありたす。



FlexPod構成の利点 。



新しい構成ず蚭蚈



デヌタセンタヌアヌキテクチャの実装に関する新しいドキュメントがリリヌスされたしたFlexPod Express、Select、およびDataCenter with Clustered Data ONTAPcDOT





テキストの゚ラヌに関するメッセヌゞをLANに送っおください。

反察にコメントず远加はコメントしおください



All Articles