Cohesity データ保護機能を利用した Cisco HyperFlex のデータ保護

Cohesity データ保護機能の Cisco C240 M5 LFF サーバ上での展開および設定ガイド（Cisco HyperFlex ESXi 環境 クラスタデータ保護）

Cohesity データ保護機能を利用したCisco HyperFlexのデータ保護（PDF）

最終更新日時：2019年3月4日

Cisco Validated Design（CVD）プログラムについて

Cisco Validated Design（CVD）プログラムは、お客様による信頼性の高い、確実かつ速やかな展開を容易にするために、デザイン、テスト、および文書化されたシステムおよびソリューションで構成されています。詳細については、次を参照してください。

http://www.cisco.com/go/designzone

このドキュメントに記載されているデザイン、仕様、表現、情報、及び推奨事項（総称して「デザイン」）は、障害も含めて本マニュアル作成時点のものです。シスコ及びそのサプライヤは、商品性の保証、特定目的への準拠の保証、及び権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保証をはじめとする、一切の保証責任を負わないものとします。いかなる場合においても、シスコ及びそのサプライヤは、このデザインを使用すること、または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはそのサプライヤに知らされていたとしても、それらに対する責任を一切負わないものとします。

デザインは予告なしに変更されることがあります。このマニュアルに記載されているデザインの使用は、すべてユーザ側の責任になります。これらのデザインは、シスコ、シスコのサプライヤ、またはシスコのパートナーからの技術的な助言や他の専門的な助言に相当するものではありません。ユーザは、デザインを実装する前に技術アドバイザに相談してください。シスコによるテストの対象外となった要因によって、結果が異なることがあります。

CCDE、CCENT、Cisco Eos、Cisco Lumin、Cisco Nexus、Cisco StadiumVision、Cisco TelePresence、Cisco WebEx、Cisco ロゴ、DCE、Welcome to the Human Network は商標です。Changing the Way We Work, Live, Play, and Learn、および Cisco Store はサービス マークです。Access Registrar、Aironet、AsyncOS、Bringing the Meeting To You、Catalyst、CCDA、CCDP、CCIE、CCIP、CCNA、CCNP、CCSP、CCVP、Cisco、Cisco Certified Internetwork Expert ロゴ、Cisco IOS、Cisco Press、Cisco Systems、Cisco Systems Capital、Cisco Systems ロゴ、Cisco Unified Computing System（Cisco UCS）、Cisco UCS B-Series Blade Servers、Cisco UCS C-Series Rack Servers、Cisco UCS S-Series Storage Servers、Cisco UCS Manager、Cisco UCS Management Software、Cisco Unified Fabric、Cisco Application Centric Infrastructure、Cisco Nexus 9000 Series、Cisco Nexus 7000 Series。Cisco Prime Data Center Network Manager、Cisco NX-OS Software、Cisco MDS Series、Cisco Unity、Collaboration Without Limitation、EtherFast、EtherSwitch、Event Center、Fast Step、Follow Me Browsing、FormShare、GigaDrive、HomeLink、Internet Quotient、IOS、iPhone、iQuick Study、LightStream、Linksys、MediaTone、MeetingPlace、MeetingPlace Chime Sound、MGX、Networkers、Networking Academy、Network Registrar、PCNow、PIX、PowerPanels、ProConnect、ScriptShare、SenderBase、SMARTnet、Spectrum Expert、StackWise、The Fastest Way to Increase Your Internet Quotient、TransPath、WebEx、および WebEx ロゴは Cisco Systems, Inc. またはその関連会社の米国および一部の国における登録商標です。

本書または Web サイトにおけるその他の商標は、第三者の知的財産です。パートナーという言葉が使用されていても、シスコとその他の会社とのパートナーシップを示すものではありません（0809R）。

© 2019 Cisco Systems, Inc. All rights reserved.

Table of Contents

エグゼクティブ サマリー... 6

ソリューションの概要... 8

はじめに... 8

対象読者... 9

このドキュメントの使用目的... 9

今回のリリースでの新機能... 9

ソリューションの概要... 10

テクノロジーの概要... 11

Cisco Unified Computing System.. 11

Cisco UCS ファブリック インターコネクト... 12

Cisco UCS 6454 ファブリック インターコネクト... 12

Cisco UCS C シリーズ Cohesity ノード... 13

Cisco UCS C240 M5 LFF サーバ... 13

Cisco UCS VIC 1457 MLOM インターフェイス カード... 13

Cohesity ソフトウェア... 14

ソリューションの設計... 16

要件... 16

物理コンポーネント... 16

ソフトウェア コンポーネント... 17

ライセンス... 17

物理トポロジ... 17

ファブリック インターコネクト... 18

Cisco UCS C シリーズ ラックマウント サーバ... 19

論理トポロジ... 20

ネットワークの設計... 21

Cisco UCS アップリンクの接続... 21

VLAN とサブネット... 24

ジャンボ フレーム... 24

考慮事項... 24

拡張性... 24

キャパシティ... 24

Configuration and Installation. 26

Prerequisites. 26

IP Addressing. 26

DNS. 27

NTP. 29

VLANs. 29

Network Uplinks. 30

Usernames and Passwords. 31

Physical Installation. 31

Cabling. 32

Cisco UCS Installation. 33

Cisco UCS Fabric Interconnect A. 33

Cisco UCS Fabric Interconnect B. 34

Cisco UCS Manager 35

Cisco UCS Configuration. 36

Cisco UCS Firmware. 36

NTP. 36

Uplink Ports. 37

Uplink Port Channels. 38

Server Ports. 39

Server Discovery. 41

Cisco UCS Organization. 42

Cisco UCS LAN Policies. 43

Cisco UCS Server Policies. 50

Cisco UCS Service Profile Templates. 57

Cohesity Installation. 61

Cohesity Software Installation. 61

Cohesity First Node Configuration. 65

Cohesity Cluster Setup. 66

Cohesity Software. 72

Cohesity Dashboard. 72

Cluster Configuration. 72

Partitions. 73

Storage Domains. 73

Time zone. 74

Security. 74

Sources. 77

Hypervisor Source. 77

Storage Snapshot Provider 78

Remote Clusters. 79

External Targets. 80

Policies. 80

Protection. 82

Recovery. 84

Views. 87

Shares. 89

Global Whitelist 90

View Protection. 90

View Recovery. 91

Test/Dev. 92

Monitoring. 93

Dashboard. 93

Performance. 94

Alerts. 95

Storage. 95

Reports. 96

SMTP. 97

SNMP. 97

Remote Support 98

Validation. 99

Test Plan. 99

Installation. 99

Core Functional Testing. 99

Extended Functional Testing. 99

Failover and Redundancy Testing. 100

Bill of Materials. 100

Summary. 102

About the Authors. 103

Acknowledgements. 103

 

日本語は部分翻訳のみ、全文は英語版を参照下さい。

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/ucsc240_cohesity_dp.html

 

業界を問わず、新しいアプリケーションやファイル形式、テクノロジーが導入されたためにデータ量が急増しています。その結果、プライマリ データとセカンダリ データの両方を維持するためのインフラ コストが上昇し、その複雑さも増加しています。それにもかかわらず、従来の非統合型の製品は拡張性に限界があるためサイロ化され、使いづらく、高コストで、展開にも時間がかかります。シスコと Cohesity の製品を組み合わせると、すべてのデータを迅速かつ容易に統合できます。統合されたハイパーコンバージド プラットフォームにより、プライマリ データとセカンダリ データの両方に優れた可視性、管理、保護、および、様々なクラウドとのアクセス連携が実現します。このように、世界規模で企業のコストを削減し、効率性を向上させ、イノベーションを促進させると同時に、簡素化、可視性、俊敏性、および複数クラウドとのデータ アクセスを可能にする統合ソリューションは他にありません。

ハイパーコンバージ ドインフラストラクチャ（HCI）は、最新のデータセンターでの採用が進みつつあります。ネットワーキング、ストレージ、およびコンピューティング リソースの統合された組み合わせにより、管理の容易さ、展開の迅速さ、および総所有コスト（TCO）が大幅に改善されます。ハイパーコンバージド インフラストラクチャにより、以前よりさらに合理化、簡素化されたアーキテクチャが実現します。これにより、変化しつづけるサービス負荷や要件に合わせてオンデマンドで拡張できる一段上のレベルの柔軟性が実現するとともに、処理サービスをより少数で小さいプラットフォームに統合できます。

ハイパーコンバージド インフラストラクチャは、当初はプライマリ ワークロードおよびデータのプラットフォームとして利用されていました。Cisco HyperFlex システムは Cisco UCS プラットフォームをベースにしており、Cisco UCS ファブリック インターコネクトを通じて、Cisco HX シリーズ x86 サーバと統合ネットワーキング技術を単一の管理ドメインに取り入れます。これには、業界をリードする VMware の仮想化ハイパーバイザ ソフトウェアと、シスコの次世代ソフトウェア デファインド ストレージ技術を組み合わせています。この組み合わせにより、すべてのインフラスタックが統合され、従来の仮想環境を最新の仮想化プラットフォーム上に構築し、ゲスト仮想マシン（VM）のネットワーク接続が容易になります。その際、特定のストレージまたはネットワーキング コンポーネントを使用することなく、VM が利用する分散ストレージはすべての Cisco UCS x86 サーバ上に分散配置されます。ただし、組織のエンタープライズ データの 80% 以上は、ミッション クリティカルではないデータ（セカンダリ データ）であると考えられます。このカテゴリには、バックアップ、アーカイブ、テスト/開発、ファイル、オブジェクト、および分析が含まれます。Cisco HyperFlex が、プライマリ ストレージ システムとしてハイパーコンバージド インフラストラクチャ市場をリードする製品として設計された原理は、セカンダリ ストレージ ワークロード向けのシステムとしても適用できます。

今日の企業は、セカンダリ データおよびアプリケーションに対して、従来アプローチによって生み出される大量のデータ フラグメンテーションという拡大しつづける問題に苦しんでいます。これに対する今までのアプローチは、非統合製品をパッチワークのように組み合わせて、これらのセカンダリ ワークフローに対応し管理しようとするものです。Vanson Bourne が実施した最近の世界市場調査によると、3 分の 1 以上の組織ですべてのセカンダリ データ操作に 6 つ以上のソリューションが使用されており、そのうちの 10% ではこの複雑なインフラストラクチャ サイロのネットワークを管理するために 11 以上のソリューションが使用されています。たとえば、一般的なエンタープライズ クラスのセカンダリ ストレージ ソリューションは、バックアップ エージェント、メディア サーバ、コントローラ サーバ、オンディスク ストレージ サーバ、およびその他のストレージ メディア システム（テープ ライブラリなど）といった複数のコンポーネントやオフサイト上のデータ保存に利用しています。このことが、セカンダリ システム内におけるデータの大幅な急増を招いています。セカンダリ システムによって保護されるプライマリ システム側でデータが無秩序に増大している可能性もありますが、この急増はそれを上回るものです。Cohesity は、ハイパーコンバージェンスの原理に基づいた独自のプラットフォームを提供しています。このプラットフォームは、Cisco Unified Computing System（UCS）アーキテクチャの処理能力および柔軟性とソフトウェア定義型ストレージを利用することで、Web 規模の統合セカンダリ データ/アプリケーション ソリューションを実現できます。このアプローチにより、従来の展開に共通した問題を回避できる統合セカンダリ ストレージ プラットフォームが提供されます。Cisco HyperFlex と Cohesity が提供するハイパーコンバージェンスの利点を活用することで、プライマリ システムとセカンダリ システムを Cisco UCS 内で単一のアーキテクチャに統合できます。このアーキテクチャにより、プライマリ/セカンダリ システムの両方に、プライマリ ワークロード ストレージ、それらのワークロードのデータ保護、それらのワークロードに対するファイル/オブジェクト サービス、およびより生産的なセカンダリ データ/アプリケーションを提供できます。

このシスコで検証済みの設計/展開ガイドでは、Cisco HyperFlex クラスタを保護する Cohesity DataPlatform（どちらも Cisco UCS ドメイン内で動作）の設計、セットアップ、設定、および継続的使用について説明し、その手順を示します。この独自の統合ソリューションは、インフラストラクチャ、運用、およびデータ管理上の課題を解決するとともに、多くのエンタープライズ データセンターにおいてセカンダリ ストレージ サイロで共通して見られるフラグメンテーションを削減するように設計されています。この非常に優れたソリューションでは、Cohesity ソフトウェアの Web 規模のシンプルさと効率性が Cisco UCS サーバの処理能力および柔軟性と結合されています。その結果、単一の統合ソリューションで、非構造化データの増加をより効率的かつ効果的に管理し、新しい洞察を獲得し、コストと複雑さを削減することができます。Cisco Cohesity 統合ソリューションの詳細については、https://www.cohesity.com/products/cisco を参照してください。

はじめに

Cisco HyperFlex システムでは、業界をリードする、Cisco UCS によるコンピューティングとネットワーキングの統合に、次世代ハイパーコンバージド ストレージ ソフトウェアを組み合わせることで、コンピューティング リソース、ネットワーク接続、ストレージ、ハイパーバイザ プラットフォームを提供し、仮想環境全体を 1 つの統一システム内で稼働させます。ハイパーコンバージド インフラストラクチャの主な利点としては、導入や日常の管理作業の簡素化に加え、俊敏性の向上による運用コストの低減などが挙げられます。ハイパーコンバージド ストレージは 一般的な IT 管理者でも簡単に管理できるため、専任の管理チームやスキルセットが必要とするストレージ システム導入での、技術面での負担も軽減されます。Cisco HyperFlex HX Data Platform は、専用の分散ログベース ファイル システムで、エンタープライズクラスのストレージ システムに必要な多数のデータ管理および最適化機能および高性能な IO を提供します。このプラットフォームでは、ストレージ リソースとコンピューティング リソースの独立した拡張、インライン圧縮/重複排除による継続的なデータ最適化、およびデータ可用性を向上させる動的データ配信に加えて、統合ネイティブ スナップショット、高速クローン作成、暗号化、および VM レベルのレプリケーションが可能です。このシステムは俊敏性に優れ、迅速に展開、管理が容易で、変化しつづけるワークロードに対応できる拡張性と柔軟性を備えています。また、高度なデータ セキュリティとデータ可用性を提供します。

Cohesity は、革新的なハイパーコンバージド セカンダリ データ/アプリケーション プラットフォームを提供します。このプラットフォームにより、セカンダリ データ アーキテクチャをより簡潔で使いやすいシステムに統合して簡素化することができます。バックアップ、リカバリ、ファイル サービス、テスト/開発、分析環境などの一般的なセカンダリ ストレージの使用ケースにおいて、単一の結束力のある統合システムに組み込み、Web ベースのインターフェイスで管理して、ポリシー駆動の制御を使用することができます。この独自のハイパーコンバージド セカンダリ データ プラットフォームにより、複雑さ、運用上の課題、およびストレージの非効率性を削減する、回復力の高い、Web 規模のセカンダリ データ ソリューションが提供されます。

Cisco UCS ドメイン内で Cisco HyperFlex と連携して動作する Cohesity により、大半の仮想化データセンターに必要なプライマリ ストレージ、ワークロード ホスティング、データ保護、およびファイル サービスのすべてを単一の統合アーキテクチャ内で提供する統合システムが実現されます。Cohesity と Cisco HyperFlex は、補完的なデータセンター テクノロジーを共有しており、その両方で、高可用性を実現するために設計された分散ファイル システム アーキテクチャが利用されています。シェアードナッシング トポロジでは、シングル ポイント障害や内在的なボトルネックは存在しません。そのため、クラスタに物理ノーを追加すれば、パフォーマンスと容量の両方が直線的に向上します。分散ファイル システムは、クラスタ内のすべてのノードにわたって広がり、グローバルな重複排除、圧縮、および暗号化をネイティブに提供します。どちらのシステムも、Cisco UCS ファブリック インターコネクトに接続されて管理される Cisco UCS x86 ラック マウント サーバ ハードウェア上に展開され、サーバ設定のポリシーベースのステートレスなプログラム制御も可能になります。

それ以外に、Cohesity システムの利点は、VMware 仮想化環境の基盤となるハードウェア プラットフォームから独立していることです。このドキュメントは、VMware ESXi ハイパーバイザによって Cisco HyperFlex を保護する Cohesity の使用例を対象としています。ただし実際には、このドキュメントに示されているガイドラインに従って展開された Cohesity システムを使用して、複数の異種 VMware 仮想化環境と、ベアメタル サーバ、データベース、クラスタ、およびネットワーク アタッチド ストレージ（NAS）ボリュームを保護し、NFS、SMB、および S3 オブジェクト ストレージによるファイル サービスを企業全体に提供することもできます。

対象読者

このドキュメントの対象読者には、セカンダリ ストレージの使用例（バックアップと復元、レプリケーション、アーカイブに加え、NFS、SMB/CIFS、および S3 を使用したオブジェクト ストレージによるファイル サービスなど）に関して Cohesity DataPlatform を理解し、展開することに関心を持つセールス エンジニア、フィールド コンサルタント、プロフェッショナル サービス、IT マネージャ、IT エンジニア、パートナー、およびお客様が含まれます。

このドキュメントの使用目的

このドキュメントでは、Cohesity DataPlatform と Cohesity DataProtect のインストール、設定、使用方法に加え、VMware ESXi ベースの Cisco HyperFlex システムの保護、および環境へのファイル サービスの提供について説明します。また、単一の Cisco UCS ドメイン内で動作させる 2 つのシステムの組み合わせに関する参照アーキテクチャを提供します。Cisco HyperFlex システム、VMware ESXi、または VMware vCenter の設計、インストール、および設定については、以前に公開された他の Cisco Validated Design ドキュメントなどで説明されているため、このドキュメントでは詳しく説明していません。Cisco HyperFlex と Cohesity の両方を含む Cisco UCS 環境の場合には、最初に Cisco HyperFlex システムをホストするようにセットアップすることをお勧めします。Cisco HyperFlex のインストールでは、一部のコンポーネントの再起動が必要になる可能性があるため、Cohesity システムの設定は、その後の二次作業として行うと、より簡単になります。

今回のリリースでの新機能

VMware スナップショット（REDO ログ テクノロジーを使用）とは異なり、Cisco HyperFlex API は、Cohesity がそのバックアップ ソリューションを HyperFlex ネイティブ スナップショットと統合することを可能にします。バックアップ製品は、一般に、バックアップを実装するための基礎として仮想マシン（VM）スナップショットを使用します。スナップショットは、アクティブ VM のバージョン（状態）を保存する固有の仮想化機能であり、次のようないくつかのシナリオで使用できます。

·         必要に応じて元に戻すことができるローカルのポイントインタイム キャプチャとして使用。これは、一般に、ゲスト OS やアプリケーションに障害が発生した場合に使用されます。

·         バックアップのシード処理を行うための一貫性のあるポイントインタイムを確立するために使用。前回のバックアップ以降に VM に加えられた変更を保存することにより、新しいスナップショットは増分バックアップに似たものになります。

·         仮想マシン クローンと仮想デスクトップ ソリューションのシード処理を行うために使用。

Cisco HyperFlex の統合により、Cohesity DataProtect ソフトウェアは、HyperFlex 上に直接 VM スナップショットを作成します。これにより、VM のストレージ ネイティブ スナップショットが作成されます。このスナップショットは HyperFlex ネイティブであるため、標準の VMware REDO ログベースのスナップショットを使用する場合のパフォーマンスとは異なり、元のベース ディスクとほぼ同等のパフォーマンス特性を持ちます。スナップショットを作成した後に Cohesity DataProtect は VM データのバックアップを行い、それが完了するとスナップショットは HyperFlex API を介して削除されます。ネイティブ スナップショットを使用する場合、一般的な遅延と I/O 上の欠点が解消され、基盤となる HyperFlex 分散ストレージ テクノロジーを使用してスナップショットを作成および統合することでアプリケーションのパフォーマンスが向上します。

ソリューションの概要

Cisco UCS ドメインで動作する Cohesity クラスタのコンポーネントは次のとおりです。

·         1 組の Cisco UCS モデル 6454 ファブリック インターコネクト

·         Cisco UCS VIC 1457 カードを搭載した 3 台以上の Cisco C240-M5L ラックマウント サーバ

·         Cohesity DataPlatform ソフトウェア

Cisco Unified Computing System

Cisco Unified Computing System（Cisco UCS）は、コンピューティング、ネットワーク、およびストレージ アクセスを統合した次世代のデータ センター プラットフォームです。仮想環境向けに最適化されており、業界標準のオープン テクノロジーを利用して設計されたもので、総所有コスト（TCO）の削減とビジネスの俊敏性強化を目的としています。このシステムは、低遅延のロスレス 10 ギガビット イーサネット、25 ギガビット イーサネット、または 40 ギガビット イーサネット ユニファイド ネットワーク ファブリックと、エンタープライズクラスの x86 アーキテクチャ サーバを統合します。これはすべてのリソースが単一の管理ドメインに集約された、統合型の拡張性に優れたマルチシャーシ対応のプラットフォームです。

Cisco Unified Computing System の主要なコンポーネント：

·         コンピューティング：Intel Xeon プロセッサをベースとしたラック サーバとブレード サーバのどちらもシステムに組み込むことができる、まったく新しいクラスのコンピューティング システムをベースとする設計。

·         ネットワーク：低遅延でロスレスの 10 Gbps、25 Gbps、または 40 Gbps ユニファイド ネットワーク ファブリックに統合。このネットワーク基盤は、LAN や SAN のほか、他のネットワークと分離るハイパフォーマンス コンピューティング ネットワークも統合します。ユニファイド ファブリックにより、ネットワーク アダプタ、スイッチやケーブルの数が減少し、電力と冷却の要件が緩和されるため、コスト削減につながります。UCS ファブリックからのアップリンク接続には、10 Gbps、40 Gbps、または 100 Gbps 接続を使用できます。

·         仮想化：仮想環境のスケーラビリティ、パフォーマンス、および運用制御を強化することで、仮想化の可能性を最大限に活用。シスコのセキュリティ、ポリシー適用、および診断機能は仮想化環境にまで拡張されており、変化するビジネス要件や IT 要件により適切に対応できます。

·         ストレージ アクセス：ユニファイド ファブリックによって SAN ストレージとネットワーク接続ストレージ（NAS）へのアクセスを統合。ストレージ アクセスを統合することにより、Cisco Unified Computing System ではイーサーネット、ファイバ チャネル、Fibre Channel over Ethernet（FCoE）、iSCSI を使用してストレージへアクセスできます。お客様は、ストレージ プロトコルと物理アーキテクチャを選択し、投資の保護を強化できます。さらに、サーバ管理者はシステムからストレージ リソースへの接続に関するストレージ アクセス ポリシーを事前に割り当てられるため、ストレージの接続と管理が簡素化され、生産性も向上します。

·         管理：あらゆるシステム コンポーネントを統合し、ソリューション全体を 1 つの管理対象として Cisco UCS Manager（UCSM）から管理可能。Cisco UCS Manager には、直感的なグラフィカル ユーザ インターフェイス（GUI）、コマンドライン インターフェイス（CLI）、堅牢なアプリケーション プログラミング インターフェイス（API）が装備され、すべてのシステム構成と運用を管理できます。

Cisco Unified Computing System の設計には、次のような特長があります。

·         総所有コスト（TCO）の削減とビジネスの俊敏性の向上

·         ジャストインタイムのプロビジョニングとサーバの流動運用性のサポートによる、IT スタッフの生産性の向上

·         データセンター内のテクノロジーの一元化を可能にする、緊密に統合されたシステム。このシステムは、管理、保守、検証などのシステムライフサイクル全体をカバーします。

·         1 ドメインあたり 160 台の物理サーバと数千台の仮想マシンに対応する設計と要件に合わせて I/O 帯域幅を拡張できる拡張性

·         業界のリーダー企業のパートナー エコシステム連携による業界標準を提供

Cisco UCS ファブリック インターコネクト

Cisco UCS ファブリック インターコネクト（FI）は、Cisco Unified Computing System の中核を成す製品であり、システムのネットワーク接続と管理機能の両方を提供します。Cisco UCS ファブリック インターコネクトは、選択したモデルに応じて、ラインレート、低遅延、ロスレス 10 ギガビット、25 ギガビット、40 ギガビット、または 100 ギガビット イーサネット、Fibre Channel over Ethernet（FCoE）、ファイバ チャネル接続を提供します。Cisco UCS ファブリック インターコネクトは、Cisco UCS C シリーズ、S シリーズ、HX シリーズのラックマウント サーバ、Cisco UCS B シリーズ ブレード サーバ、Cisco UCS 5100 シリーズ ブレード サーバ シャーシの管理および通信のバックボーンになります。Cisco UCS ファブリック インターコネクトに接続されるすべてのサーバとシャーシ、つまりすべてのブレードが一体となり、可用性の高い単一の管理ドメインを形成します。さらに、Cisco UCS ファブリック インターコネクトはユニファイド ファブリックをサポートしているため、ドメイン内のすべてのサーバが LAN と SAN の両方にシンプルなケーブリングで接続できます。

優れたネットワーキング パフォーマンスのために、Cisco UCS 6454 シリーズは、カットスルー アーキテクチャを採用しています。そのため、確定的な低遅延のライン レート 10/25/40/100 ギガビット イーサネット ポート、3.82 Tbps のスイッチング容量、および Cisco 5108 ブレード シャーシあたり 320 Gbps の帯域幅（IOM 2208 モデルによる接続時）をサポートします。また、シスコの低遅延でロスレスの 10/25/40/100 ギガビット イーサネット ユニファイド ネットワーク ファブリック機能をサポートするため、イーサネット ネットワークの信頼性、効率性と拡張性が向上します。ファブリック インターコネクトは、サーバからアップリンクまで、イーサネット ファブリック上で複数のトラフィック クラスをサポートします。ネットワーク インターフェイス カード（NIC）、ホスト バス アダプタ（HBA）、ケーブル、スイッチを統合可能な FCoE が最適化されたサーバ設計によって、TCO を大幅に削減できます。

Cisco UCS 6454 ファブリック インターコネクト

Cisco UCS 6454 ファブリック インターコネクトは、1 ラック ユニット（1RU）の 10/25/40/100 ギガビット イーサネット、FCoE、およびファイバ チャネル スイッチで、最大 3.82 Tbps のスループットと最大 54 個のポートを提供します。スイッチには 8 個の 10/25 Gbps 固定イーサネット ポート（オプションで 8/16/32 Gbps FC ポートに設定可能）（ポート1 〜 8）、36 個の 10/25 Gbps 固定イーサネット ポート（ポート 9 〜 44）、4 個の1/10/25 Gbps イーサネット ポート（ポート 45 〜 48）、さらに 6 個の 40/100 Gbps イーサネット アップリンク ポート（ポート 49 〜 54）があります。

図 1     Cisco UCS 6454 ファブリック インターコネクト

Cisco UCS C シリーズ Cohesity ノード

Cohesity クラスタには（ディスク ストレージと共に）最低 3 つの Cisco UCS C シリーズ「コンバージド」ノードが必要です。データはこれらのうち最低 2 つのノードで複製され、3 番目のノードは単一ノードの障害時に運用を継続する上で必要になります。各ノードには 2 台の優れたパフォーマンスの SSD ドライブが搭載されており、データ キャッシュと書き込み要求への迅速な応答（ACK）を可能にしています。また各ノードには、長期的なストレージと全体的な容量に対応するために、ハードディスクを追加することも可能です。

Cisco UCS C240 M5 LFF サーバ

この 2 ラック ユニット（2RU）のCisco C240 M5 ラージ フォーム ファクタ（LFF）モデル サーバには、ブート ドライブとして機能する 1 組の 240 GB M.2 フォーム ファクタ SSD、1 組の 1.6 TB または 3.2 TB NVMe SSDドライブ（背面ドライブ スロットに搭載）、およびストレージ容量としての 12 台の 4 TB または 10 TB SATA HDDドライブが搭載されます。

図 2     Cisco C240 M5 LFF サーバ

Cisco UCS VIC 1457 MLOM インターフェイス カード

Cisco UCS VIC 1457 カードは、Cisco UCS C シリーズ ラック サーバに搭載可能なカードで、拡張された着脱可能スモール フォームファクタ（SFP+）の 10/25 Gbps イーサネットおよび Fibre Channel over Ethernet（FCoE）対応のポートを 4 ポート搭載した、PCI Express（PCIe）モジュール型 LAN On Motherboard（mLOM）アダプタです。VIC 1457 は、Cisco UCS 6454 モデルのファブリック インターコネクトとの接続に利用します。mLOM スロットを使用すれば PCIe スロットを使用せずに Cisco VIC を構成できるため、I/O の拡張性が向上します。シスコの次世代統合型ネットワーク アダプタ（CNA）テクノロジーを取り入れることで、将来の機能リリースにおける投資を保護します。このカードにより、ポリシーベースでステートレス、かつ俊敏性に優れたサーバ インフラストラクチャが実現します。PCIe 標準準拠のインターフェイスを最大 256 個までホストに提供可能で、ネットワーク インターフェイス カード（NIC）またはホスト バス アダプタ（HBA）として動的に構成できます。インターフェイスの特性は、サーバに関連付けられたサービス プロファイルを使用したプログラミングによって設定されます。サービス プロファイルでは、PCIe インターフェイスの番号、タイプ（NIC または HBA）、ID（MAC アドレスおよび World Wide Name（WWN））、フェールオーバー ポリシー、アダプタ設定、帯域幅、Quality of Service（QoS）ポリシーを指定できます。

図 3     Cisco UCS VIC 1457 mLOM カード

Cohesity ソフトウェア

Cohesityは、セカンダリ データの無秩序な増加やインフラストラクチャのサイロ化という拡大しつづける課題に対処します。これは、バックアップ、ディザスタ リカバリ、ファイル サービス、オブジェクト ストレージ、テスト/開発、アーカイブ、分析などのすべてのセカンダリ データおよびアプリケーションを、オンプレミス インフラストラクチャからクラウドやリモート オフィスまたはブランチ オフィスにおよぶ Web 規模のシンプルなソフトウェア定義型プラットフォームに統合することによって行います。プライマリ データ用の Cisco HyperFlex を補完する Cohesity ソフトウェアが Cisco UCS と統合されることにより、セカンダリ データおよびアプリケーションの保護が強化されるとともに、それらの生産性が向上します。

·         すべてのセカンダリ データおよびアプリケーションに対応できる唯一の Web 規模のハイパーコンバージド プラットフォーム

Cohesity は、Web 規模のハイパーコンバージド プラットフォーム上に構築される、業界で唯一のセカンダリ データ/アプリケーション ソリューションを提供しています。Google に似た設計原理を持つこのソリューションは、真にグローバルな重複排除と、エッジからコアへ、さらにはクラウドまでの非常に優れたストレージ効率を実現して、バックアップ、アーカイブ、ファイル、オブジェクト、テスト/開発、および分析に関する課題を解決します。Cohesity は、エッジからクラウドまでのセカンダリ データおよびアプリケーションに Web 規模のシンプルさを提供し、サイロを排除して、データの活用を可能にします。Global 2000 の企業や連邦政府機関などで、高い評価を得ている Cohesity ソリューションを使用して、モダナイゼーションと規模の拡大を進めています。

·         エンドツーエンドのデータ保護、アーカイブ、およびインスタント リカバリ

Cohesity は、他に例のないエンドツーエンドのバックアップ/リカバリ ソリューションを提供しています。このソリューションは、シンプルなデータ保護、アーカイブ、わずか数分の目標復旧時点（RPO）、即座の目標復旧時間（RTO）、および瞬時の大量復元を提供すると同時に、データ保護コストを最大半分以下に削減します。

·         ネイティブ パブリック クラウド統合

Cohesity プラットフォームは、パブリック クラウドを念頭に置いて構築されています。Cohesity のクラウドファーストのアーキテクチャは、制御を維持しながらパブリック クラウドのコストと経済効率の利点を活用するという企業の目標を達成するために役立ちます。Cohesity を使用すると、長期間の保持、アーカイブ、ディザスタ リカバリ、テスト/開発、およびクラウド バックアップのすべてを同じプラットフォームで実現できます。

·         ユニファイド マネジメント

SaaS ベースの管理ソリューションを提供しているのは Cohesity だけです。これは、エッジ、コア、およびクラウドにわたるすべてのセカンダリ データ/アプリケーション インフラストラクチャをグローバルに統合し、単一のコンソールで一元管理できるようにします。また、このソリューションには機械学習が組み込まれており、グローバルな IT の生産性を改善し、ビジネスのプランニングと継続性の向上させ、これまで活用されていなかったセカンダリ データから貴重な洞察を得ることを可能にします。

要件

以下のセクションでは、Cisco Unified Computing Systemで動作する Cohesity DataPlatform の単一のクラスタをインストールするために必要な物理ハードウェア、ソフトウェア リビジョン、およびファームウェア バージョンについて詳しく説明します。

物理コンポーネント

表 1        Cohesity DataPlatform システム コンポーネント

サーバ仕様と詳細については、以下のリンクを参照してください。

Cisco ファブリック インターコネクト 6454：

https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-b-series-blade-servers/ucs-6454-fab-int-specsheet.pdf

Cisco UCS C240 M5 LFF サーバ：

https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/c240m5-lff-specsheet.pdf

‎表 2に、Cohesity DataPlatform のインストールに必要な Cisco UCS C240-M5L サーバ モデルの必須ハードウェア コンポーネントおよびディスク オプションを示します。

表 2        Cisco UCS C240 M5 LFF サーバのオプション

 

ソフトウェア コンポーネント

‎表 3に、このドキュメントでテストされ、検証される、Cisco UCS システムで動作する Cohesity DataPlatform の単一クラスタに必要なソフトウェア コンポーネントとそのバージョンを示します。

表 3        ソフトウェア コンポーネント

ライセンス

Cisco UCS システムと Cohesity ソフトウェアは、使用中のすべてのソフトウェア機能と、Cisco UCS ファブリック インターコネクトで使用中のすべてのポートに関して、適切にライセンスが付与されている必要があります。ソリューションで必要かつ適切なライセンスをすべて注文したことを確認するには、再販パートナーまたはシスコと Cohesity の直販チームにご連絡ください。

物理トポロジ

トポロジ概要

Cisco Unified Computing System は、1 対の Cisco UCS ファブリック インターコネクトと、UCS ドメインあたり最大 160 台の B シリーズ ブレード サーバ、Cisco UCS C シリーズ ラックマウント サーバ、HX シリーズ ハイパーコンバージド サーバ、または S シリーズ ストレージ サーバで構成されます。Cisco UCS ドメイン内では、さまざまなワークロードに対して複数の環境を展開できます。たとえば、Cisco HyperFlex クラスタは Cisco HX シリーズ ラックマウント サーバを使用して構築でき、Cohesity クラスタは Cisco C シリーズラックマウントサーバを使用して構築できます。また、Cisco 5108 ブレード シャーシ内部の Cisco UCS B シリーズ ブレード サーバはさまざまなベアメタルまたは仮想化環境に使用でき、Cisco UCS S シリーズ ストレージ サーバは高密度ストレージ用に展開できます。2 つのファブリック インターコネクトはどちらもすべての Cisco UCS C シリーズ、HX シリーズ、または Cisco UCS S シリーズ ラックマウントサーバに接続され、またどちらもすべての Cisco UCS 5108 ブレード シャーシに接続されます。インストール時には、ファブリック インターコネクトから顧客のデータセンター ネットワークに、ノースバウンド ネットワーク接続とも呼ばれるアップストリーム ネットワーク接続が行われます。

図 4     Cisco UCS の物理トポロジの例

ファブリック インターコネクト

Cisco UCS ファブリック インターコネクト（FI）は、管理クラスタとして動作する 2 つのユニットがペア構成で展開され、A サイド ファブリックおよび B サイド ファブリックからなる 2 つの別個のネットワーク ファブリックを構成します。そのため、設計上の要素表記として、FI A や FI B またはファブリック A、ファブリック B という呼称が用いられます。これらのファブリック インターコネクトは両方とも常にアクティブで、冗長構成や高可用性構成のためのネットワーク ファブリック上でデータを通過させます。Cisco UCS Manager などの管理サービスにおいても、2 つの FI がクラスタ形式で提供されます。つまり、一方の FI がプライマリでもう一方の FI がセカンダリとなり、クラスタ化されたローミング IP アドレスが付与されます。このプライマリ/セカンダリの関係は管理クラスタに関してのみであり、データ伝送には影響を与えません。

ファブリック インターコネクトには以下のポートがあり、Cisco UCS ドメインの適切な管理のためには、それらのポートに接続する必要があります。

·         Mgmt：GUI または CLI ツールを通じて、ファブリック インターコネクトや Cisco UCS ドメインを管理する際に使用するポート（10/100/1000 Mbps）です。このポートは、ドメイン内の管理対象サーバへのリモート KVM、IPMI、SoL セッションにも使用されます。これは通常、管理ネットワークに接続されます。

·         L1：Cisco UCS 管理クラスタを構成する際のクロス接続ポートです。このポートは、RJ45 プラグを備えた標準の CAT5/CAT6 イーサネット ケーブルを使用して、ファブリック インターコネクトのペアの L1 ポートに直接接続されます。スイッチやハブに接続する必要はありません。

·         L2：Cisco UCS 管理クラスタを構成する際のクロス接続ポートです。このポートは、RJ45 プラグを備えた標準の CAT5/CAT6 イーサネット ケーブルを使用して、ファブリック インターコネクトのペアの L2 ポートに直接接続されます。スイッチやハブに接続する必要はありません。

·         Console：ファブリック インターコネクトに直接コンソール アクセスを行うための RJ45 シリアル ポートです。通常、このポートは RJ45 アダプタを備えたシリアル ケーブルを使用して、FI の初期設定プロセスを実施する際に使用されます。また、ターミナル アグリゲータ、またはリモート コンソール サーバ デバイスにも接続できます。

Cisco UCS C シリーズ ラックマウント サーバ

Cohesity UCS クラスタには、3 台以上の Cisco UCS C240 M5 LFF ラックマウント サーバが必要です。Cisco UCS S シリーズ ラックマウント サーバは、Cisco UCS ファブリック インターコネクトに、直接接続モードで接続されます。内部的には、Cisco UCS C シリーズ サーバは、Cisco VIC 1457 ネットワーク インターフェイス カード（NIC）を、クアッド 10/25 ギガビット イーサネット（GbE）ポートを備えたモジュール型 LAN on Motherboard（MLOM）スロットに取り付けて構成することができます。標準の冗長接続方式では、各サーバの VIC カードのポート 1 を FI A の番号付きポートに接続し、各サーバの VIC カードのポート 3 を FI B の同じ番号付きポートに接続します。ポート 1 と 3 を使用する理由は、ポート 1 とポート 2 が内部ポート チャネルを形成し、ポート 3 とポート 4 が内部ポート チャネルを形成するためです。これにより、オプションの 4 ケーブル接続方法が可能になります（今回の設計では使用しません）。

 

図 5     Cisco UCS C シリーズ サーバの接続

論理トポロジ

論理ネットワークの設計

Cisco UCS 上で動作する Cohesity DataPlatform には、次の 2 つの定義済みゾーンに接続される通信経路があります（‎図 6）。

·         管理ゾーン：このゾーンは、物理ハードウェアを管理するために必要な接続と Cisco UCS ドメインの設定で構成されます。これらのインターフェイスと IP アドレスは、LAN や WAN の全体で、UCS システムを管理する担当者全員で利用できる必要があります。このゾーンのすべての IP アドレスは、同じレイヤ 2（L2）サブネットから割り当てられる必要があります。このゾーンは、ドメイン ネーム システム（DNS）サービスと Network Time Protocol（NTP）サービスへのアクセスを提供し、HTTP/S およびセキュアシェル（SSH）を介した通信が許可されている必要があります。このゾーンは、複数の物理コンポーネントと仮想コンポーネントからできています。

-         ファブリック インターコネクト管理ポート。

-         各ラックマウント型サーバおよびブレードによって使用される Cisco Intelligent Management Controller（CIMC）管理インターフェイス。これらは、FI 管理ポートを介して応答します。

·         アプリケーション ゾーン：このゾーンは、Cohesity DataPlatform ソフトウェアおよびノード上の基盤となるオペレーティング システムによって使用される接続で構成されます。適切に運用するためには、これらのインターフェイスと IP アドレスが相互に通信できる必要があります。また、それらは、同じ L2 サブネットから割り当てられる必要があります。Cohesity アプリケーション トラフィックに使用される VLAN は、Cohesity によって保護されるすべての環境（Cisco HyperFlex ノードの管理インターフェイスなど）や、その管理 vCenter Server システムとも、相互にアクセス可能である必要があります。このゾーンは、ドメイン ネーム システム（DNS）サービスと Network Time Protocol（NTP）サービスへのアクセスを提供し、HTTP/S およびセキュアシェル（SSH）を介した通信が許可されている必要があります。さらに、ファイル サービスのために Cohesity に接続するクライアントも、この VLAN にアクセスできる必要があります。最後に、VLAN は、Cisco UCS ドメインからのネットワーク アップリンクを通過し、ノースバウンド スイッチを介して FI B から FI A（およびその逆）に直接到達できる必要があります。このゾーンには、複数のコンポーネントがあります。

-         各 Cohesity ノードの基盤となる Linux オペレーティング システム用に設定された静的 IP アドレス。ノードごとに 2 つの UCS vNIC（1 つは A 側ファブリック上、もう 1 つは B 側ファブリック上）が設定されます。2 つのインターフェイスは、ボンディング モード 1（アクティブ/パッシブ）を使用して、Linux オペレーティングシステム内のボンディングでスレーブ インターフェイスとして設定されます。

-         Cohesity がすべての管理、バックアップ、およびファイル サービス アクセスに使用する、ノードあたり 1 つの浮動仮想 IP アドレス（VIP）。アドレスの割り当ては Cohesity ソフトウェアによって処理され、いずれかのノードがオフラインになると、利用可能なノードに再割り当てされます。これらの浮動アドレスはすべて DNS 内で単一の A レコードに割り当てられます。また、DNS サーバは、DNS ラウンドロビンを使用してその A レコードに関するクエリに応答する必要があります。

図 6     論理ネットワークの設計

ネットワークの設計

Cisco UCS アップリンクの接続

Cisco UCS ネットワーク アップリンクは、Cisco UCS ファブリック インターコネクトのペアからお客様のデータセンターの LAN に「ノースバウンド」を接続します。Cisco UCS のすべてのアップリンクは、アップリンクをまたいで複数の 802.1Q VLAN ID を伝送するトランクとして動作します。Cisco UCS のデフォルトの動作は、Cisco UCS の設定で定義されたすべての VLAN ID を利用可能なすべてのアップリンクでトランキングできることを前提としています。

Cisco UCS ファブリック インターコネクトは、別のネットワーク スイッチではなく、エンドポイントの集合としてネットワーク上に表示されます。内部では、ファブリック インターコネクトはスパニングツリー プロトコル（STP）ドメインに参加していません。また、レイヤ 2 のイーサネット リンクで相互に接続されていないため、ネットワーク ループを形成できません。STP を介したすべてのリンク アップ/ダウンの決定は、アップストリームのルート ブリッジによって行われます。

アップリンクは、両方のファブリック インターコネクトから接続してアクティブにする必要があります。冗長性を確保するため、各 FI で複数のアップリンクを、802.3ad Link Aggregation Control Protocol（LACP）ポート チャネルとしてまたは個々のリンクを使って使用できます。パフォーマンスと冗長性を最適なレベルにするために、バーチャル ポート チャネル（vPC）機能を使って、アップリンクを複数のアップストリーム シスコ スイッチの LACP ポート チャネルとして作成できます。vPC アップリンクを使用すると、すべてのアップリンクをアクティブ通過データにすることができるうえ、個別のリンク障害や、アップストリーム スイッチの故障から保護することができます。他のアップリンク設定を冗長にすることができますが、vPC が使用できない場合、スパニングツリー プロトコルのループ回避によってリンクが無効になる場合があります。

すべてのアップリンク接続方式では、1 つのファブリック インターコネクトから別のファブリック インターコネクトへ、つまりファブリック A からファブリック B へトラフィックを渡すことができなければなりません。ケーブル、ポート、またはリンクの障害によって、通常は Cisco UCS ドメインから出ないトラフィックを Cisco UCS アップリンクに強制的に転送しなければならない場合があります。また、このトラフィック フロー パターンは、ファブリック インターコネクトでのファームウェアの更新など、再起動を必要とするメンテナンス手順中に一時的に確認できます。以下のセクションと図で、いくつかのアップリンク接続オプションについて詳しく説明します。

単一のアップリンクを単一のスイッチに

これは、いくつかの点で障害に弱い接続設計です。いずれかのファブリック インターコネクトで単一のアップリンク障害が発生すると接続損失や機能障害が発生する可能性があり、単一のアップリンク スイッチの障害によって完全な接続障害が発生する可能性があります。

図 7     単一のアップリンクを使用して単一のスイッチに接続

ポート チャネルを単一のスイッチに

この接続設計は、単一のリンクの損失に対する冗長性を持ちますが、単一のスイッチの障害に弱いままです。

図 8     ポート チャネルを使用して単一のスイッチに接続

 

単一のアップリンクまたはポート チャネルを複数のスイッチに

この接続設計は、アップストリーム スイッチの障害に対する冗長性を持ち、単一のリンクの障害に対する冗長性も持ちます。通常の運用では、2 つのアップストリーム スイッチ間のループを回避するために、STP によってリンクの半分がブロックされる可能性があります。これの副作用として、Cisco UCS ドメインと LAN の間の帯域幅が減少します。アクティブ リンクのいずれかに障害が発生した場合、STP は、以前にブロックしていたリンクをオンラインにして、他のスイッチを介してそのファブリック インターコネクトにアクセスできるようにします。単一の FI から単一のスイッチへの両方のリンクを接続することは推奨されません。これは、この構成では単一のスイッチの障害によってファブリック A からファブリック B への接続が切断される可能性があるためです。冗長性を強化するために、次の図に示されている単一のリンクをポートチャネルにすることも可能です。

図 9     複数のアップリンク スイッチを使用して接続

vPC と複数スイッチ間

この推奨接続設計は、VSS を実行している Catalyst 6000 シリーズ スイッチ、Cisco Nexus 5000 シリーズ、および Cisco Nexus 9000 シリーズのスイッチなど、バーチャル ポート チャネル機能を備えたシスコのスイッチを使用します。論理的に、2 つの vPC 対応スイッチは 1 つのスイッチとして出現するため、スパニングツリー プロトコルはどのリンクもブロックしません。この設定ではすべてのリンクをアクティブにすることができるため、最大帯域幅と、レベルごとの複数の冗長性が実現されます。

図 10   vPC を使用した接続

VLAN とサブネット

Cohesity システムの構成では、アップストリーム LAN から Cisco UCS ドメインに伝送する必要がある VLAN は 1 つだけであり、この VLAN も Cisco UCS の設定で定義されます。‎表 4 に、Cisco UCS 内の Cohesity に必要な VLAN とその機能を示します。

表 4        VLAN

ジャンボ フレーム

<<cohesity_vlan>> VLAN およびサブネットを通過するすべての Cohesity トラフィックは、デフォルトでは、標準イーサネット フレームを使用するように設定されます。

考慮事項

クラスタをインストールする前に、Cohesity クラスタに必要なノード数と、それによって生じる使用可能容量について熟慮する必要があります。

拡張性

Cohesity クラスタには、初期クラスタを作成するために 3 台以上の Cisco C240 M5 LFF ラックマウント サーバ ノードが必要です。このクラスタは、そこから、エンドユーザが必要とする、全体的なストレージ スペース要件を満たす規模のクラスタに拡張できます。この無制限の拡張は Cohesity によって提供される重要な機能であり、これによって、全体的な容量の制限に達することを心配せずに将来にわたって拡張できます。

キャパシティ

全体的なクラスタの使用可能容量はいくつかの要因によって決まりますが、主要な要因はクラスタ内のノード数と、容量レイヤのディスクの数およびサイズです。キャッシュ ディスクのサイズは、クラスタ容量の一部として計算されません。スペースの消費量は、Cohesity クラスタに作成されるストレージ ドメインで設定される複製係数の直接的な結果です。さらに、着信データの重複排除および圧縮は、保存されるデータの効率性に影響を与えます。Cohesity クラスタの使用可能容量と使用済み容量のについての信頼できる情報は、Cohesity HTML 管理ダッシュボードによって提供されます。

ディスク ドライブの製造元は、10 進プレフィックスとも呼ばれる 10 の累乗の計算を使用するサイズ レポート手法を採用しています。たとえば、120 GB ディスクは、120 x 10^9 バイトのアドレス指定可能容量、または 1,200 億バイト以上と表されています。ただし、多くのオペレーティング システムとファイルシステムは、標準コンピュータのバイナリ累乗法またはバイナリ プレフィックスと呼ばれる 2 の累乗の計算に基づいてスペースを報告します。この例では、2^10 または 1024 バイトが 1 キロバイトに相当し、2^10 キロバイトが 1 メガバイトに相当します。2^10 メガバイトは 1 ギガバイトに相当し、2^10 ギガバイトが 1 テラバイトに相当します。値が増えるほど、2 つの測定系と表記の差が大きくなり、テラバイト レベルでは、10 進プレフィックス値とバイナリ プレフィックス値の差が 10% 近くになります。

国際単位系（SI）では、10 の累乗による値と 10 進プレフィックスが次のように定義されています。

表 5        SI 単位の値（10 進プレフィックス）

国際標準化機構（ISO）および国際電気標準会議（IEC）は、ISO/IEC 80000-13:2008 Clause 4 で、2 の累乗の値とバイナリ プレフィックスを次に示すように定義しています。

表 6        IEC 単位の値（バイナリ プレフィックス）

本書の目的において、それぞれの製造元が指定しているように、10 進プレフィックス数を未加工のディスク容量にのみ使用します。Cohesity ソフトウェア、ファイルシステム、またはオペレーティング システムの観点から未加工の（または使用可能な）容量値が表示される計算では、バイナリ プレフィックス数が使用されます。その主な理由は、Cohesity HTML 管理ダッシュボード内でクラスタ容量、割り当てと使用量を確認する際や、大半の OS 内（の画面表示）で、エンド ユーザに一貫性のある一連の値を表示すためです。

‎表 7に、クラスタのアレイ構成でバイナリ プレフィックスを使用した Cohesity DataPlatform クラスタの、利用可能容量値のセットを示します。これらの値は、初期購入時の Cohesity クラスタの適切なサイズを判断するために容量値を算出する際に参考になります。重複排除と圧縮によるさらなる節約によって、ノードの物理容量をはるかに超える実効論理容量が実現されます。さらに、複製係数として 2 を選択すること、またはイレージャ コーディングによって、ノードに保存される実際のデータの全体的な効率が決まります。

表 7        Cohesity クラスタの使用可能な物理容量

 

Installing the Cohesity DataPlatform system is done through mounting a virtual DVD image to each Cisco C240 M5 node, which is available for download from Cohesity as an ISO file. The installation DVD validates the hardware configuration, installs the Linux operating system, copies the Cohesity software packages, and completes with the nodes ready for their final configuration to form a cluster. Prior to using the installation DVD, the configuration of the Cisco UCS domain, its policies, templates, and service profiles to be associated to the servers must be completed. The following sections will guide you through the prerequisites and manual steps needed to configure Cisco UCS Manager prior to booting the Cohesity installation DVD, the steps to install Cohesity to each node, and how to perform the remaining post-installation tasks to configure the Cohesity cluster. Finally, a basic configuration example is given for configuring Cohesity Storage Domains, Sources, Policies, Protection Jobs, file services Views, and Test/Dev VM services.

Prerequisites

Prior to beginning the installation activities, perform the following necessary tasks and gather the required information:

IP Addressing

IP addresses for the Cohesity system on Cisco UCS need to be allocated from the appropriate subnets and VLANs to be used. IP addresses that are used by the system fall into the following groups:

·         UCS Management: These addresses are used and assigned by Cisco UCS Manager. Three IP addresses are used by Cisco UCS Manager; one address is assigned to each Cisco UCS Fabric Interconnect, and the third IP address is a roaming address for management of the Cisco UCS cluster. In addition, at least one IP address per Cisco UCS C-series rack-mount server is required for the Cohesity external management IP address pool, which are assigned to the CIMC interface of the physical servers. Since these management addresses are assigned from a pool, they need to be provided in a contiguous block of addresses. These addresses must all be in the same subnet.

·         Cohesity Application: These addresses are used by the Linux OS on each Cohesity node, and the Cohesity software. Two IP addresses per node in the Cohesity cluster are required from the same subnet. These addresses can be assigned from the same subnet at the Cisco UCS Management addresses, or they may be separate.

The following tables will assist with gathering the required IP addresses for the installation of a 4-node standard Cohesity cluster by listing the addresses required, plus an example IP configuration:

Table 8     Cohesity Cluster IP Addressing

Table 9     Example Cohesity Cluster IP Addressing

DNS

DNS servers are required to be configured for querying Fully Qualified Domain Names (FQDN) in the Cohesity application group. DNS records need to be created prior to beginning the installation. At a minimum, it is required to create a single A record for the name of the Cohesity cluster, which answers with each of the virtual IP addresses used by the Cohesity nodes in round-robin fashion. Some DNS servers are not configured by default to return multiple addresses in round-robin fashion in response to a request for a single A record, please ensure your DNS server is properly configured for round-robin before continuing. The configuration can be tested by querying the DNS name of the Cohesity cluster from multiple clients, and verifying that all of the different IP addresses are given as answers in turn.

The following tables will assist with gathering the required DNS information for the installation, by listing the information required, and an example configuration:

Table 10  DNS Server Information

Table 11  DNS Server Example Information

NTP

Consistent time clock synchronization is required across the components of the Cohesity cluster, provided by reliable NTP servers, accessible for querying in the Cisco UCS Management network group, and the Cohesity Application group. NTP is used by many components, such as Cisco UCS Manager, vCenter, the Cohesity cluster nodes, and the HyperFlex Storage Platform. The use of public NTP servers is highly discouraged, instead a reliable internal NTP server should be used.

The following tables will assist with gathering the required NTP information for the installation by listing the information required, and an example configuration:

Table 12  NTP Server Information

Table 13  NTP Server Example Information

VLANs

Prior to the installation, the required VLAN IDs need to be documented, and created in the upstream network if necessary. There is one VLAN that needs to be trunked to the two Cisco UCS Fabric Interconnects which manage the Cohesity cluster; the VLAN for the Cohesity Application group. The VLAN IDs must be supplied during the Cisco UCS configuration steps, and the VLAN names should be customized to make them easily identifiable.

The following tables will assist with gathering the required VLAN information for the installation by listing the information required, and an example configuration:

Table 14  VLAN Information

Table 15  VLAN Example Information

Network Uplinks

The Cisco UCS uplink connectivity design needs to be finalized prior to beginning the installation. Refer to the network uplink design possibilities in the Network Design section.

The following tables will assist with gathering the required network uplink information for the installation by listing the information required, and an example configuration:

Table 16  Network Uplink Configuration

 

Table 17  Network Uplink Example Configuration

Usernames and Passwords

Several usernames and passwords need to be defined or known as part of the Cohesity installation and configuration process. The following tables will assist with gathering the required username and password information by listing the information required and an example configuration:

Table 18  Usernames and Passwords

Table 19  Example Usernames and Passwords

Physical Installation

Install the Fabric Interconnects and the Cisco UCS C-Series rack-mount servers according to their corresponding hardware installation guides listed below.

Cisco UCS 6454 Fabric Interconnect:

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/hw/6454-install-guide/6454.pdf

Cisco UCS C240 M5 LFF rack-mount server:

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/hw/C240M5/install/C240M5.pdf

Cabling

The physical layout of the Cohesity system was previously described in section Physical Topology. The Fabric Interconnects and C-series rack-mount servers need to be cabled properly before beginning the installation activities.

Table 20provides an example cabling map for installation of a Cohesity system, using four C-Series Cohesity converged nodes as tested in this document.

Table 20  Example Cabling Map

Cisco UCS Installation

This section describes the steps to initialize and configure the Cisco UCS Fabric Interconnects, to prepare them for the Cohesity installation. For installations of Cohesity being integrated into an existing Cisco UCS domain, the following steps outlining the initial setup of the Fabric Interconnects, and their uplink port configuration can be skipped. In this situation, the steps beginning with the configuration of the server ports and server discovery onwards, including sub-organizations, policies, pools, templates and service profiles, must still be performed.

Cisco UCS Fabric Interconnect A

To configure Fabric Interconnect A, complete the following steps:

1.    Make sure the Fabric Interconnect cabling is properly connected, including the L1 and L2 cluster links, and the management ports, then power the Fabric Interconnects on by inserting the power cords.

2.    Connect to the console port on the first Fabric Interconnect, which will be designated as the A fabric device. Use the supplied Cisco console cable (CAB-CONSOLE-RJ45=), and connect it to a built-in DB9 serial port, or use a USB to DB9 serial port adapter.

3.    Start your terminal emulator software.

4.    Create a connection to the COM port of the computer’s DB9 port, or the USB to serial adapter. Set the terminal emulation to VT100, and the settings to 9600 baud, 8 data bits, no parity, and 1 stop bit.

5.    Open the connection which was just created. You may have to press ENTER to see the first prompt.

6.    Configure the first Fabric Interconnect, using the following example as a guideline:

           ---- Basic System Configuration Dialog ----

 

  This setup utility will guide you through the basic configuration of

  the system. Only minimal configuration including IP connectivity to

  the Fabric interconnect and its clustering mode is performed through these steps.

 

  Type Ctrl-C at any time to abort configuration and reboot system.

  To back track or make modifications to already entered values,

  complete input till end of section and answer no when prompted

  to apply configuration.

 

 

  Enter the configuration method. (console/gui) ? console

 

  Enter the setup mode; setup newly or restore from backup. (setup/restore) ? setup

 

  You have chosen to setup a new Fabric interconnect. Continue? (y/n): y

 

  Enforce strong password? (y/n) [y]: y

 

  Enter the password for "admin":

  Confirm the password for "admin":

 

  Is this Fabric interconnect part of a cluster(select 'no' for standalone)? (yes/no) [n]: yes

 

  Enter the switch fabric (A/B) []: A

 

  Enter the system name:  HX1-FI

 

  Physical Switch Mgmt0 IP address : 10.29.133.104

 

  Physical Switch Mgmt0 IPv4 netmask : 255.255.255.0

 

  IPv4 address of the default gateway : 10.29.133.1

 

  Cluster IPv4 address : 10.29.133.106

 

  Configure the DNS Server IP address? (yes/no) [n]: yes

 

    DNS IP address : 10.29.133.110

 

  Configure the default domain name? (yes/no) [n]: yes

 

    Default domain name : hx.lab.cisco.com

 

  Join centralized management environment (UCS Central)? (yes/no) [n]: no

 

  Following configurations will be applied:

 

    Switch Fabric=A

    System Name=HX1-FI

    Enforced Strong Password=no

    Physical Switch Mgmt0 IP Address=10.29.133.104

    Physical Switch Mgmt0 IP Netmask=255.255.255.0

    Default Gateway=10.29.133.1

    Ipv6 value=0

    DNS Server=10.29.133.110

    Domain Name=hx.lab.cisco.com

 

    Cluster Enabled=yes

    Cluster IP Address=10.29.133.106

    NOTE: Cluster IP will be configured only after both Fabric Interconnects are initialized

 

  Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no): yes

  Applying configuration. Please wait.

 

  Configuration file - Ok

Cisco UCS Fabric Interconnect B

To configure Fabric Interconnect B, complete the following steps:

1.    Connect to the console port on the first Fabric Interconnect, which will be designated as the B fabric device. Use the supplied Cisco console cable (CAB-CONSOLE-RJ45=), and connect it to a built-in DB9 serial port, or use a USB to DB9 serial port adapter.

2.    Start your terminal emulator software.

3.    Create a connection to the COM port of the computer’s DB9 port, or the USB to serial adapter. Set the terminal emulation to VT100, and the settings to 9600 baud, 8 data bits, no parity, and 1 stop bit.

4.    Open the connection which was just created. You may have to press ENTER to see the first prompt.

5.    Configure the second Fabric Interconnect, using the following example as a guideline:

           ---- Basic System Configuration Dialog ----

 

  This setup utility will guide you through the basic configuration of

  the system. Only minimal configuration including IP connectivity to

  the Fabric interconnect and its clustering mode is performed through these steps.

 

  Type Ctrl-C at any time to abort configuration and reboot system.

  To back track or make modifications to already entered values,

  complete input till end of section and answer no when prompted

  to apply configuration.

 

 

  Enter the configuration method. (console/gui) ? console

 

  Installer has detected the presence of a peer Fabric interconnect. This Fabric interconnect will be added to the cluster. Continue (y/n) ? y

 

  Enter the admin password of the peer Fabric interconnect:

    Connecting to peer Fabric interconnect... done

    Retrieving config from peer Fabric interconnect... done

    Peer Fabric interconnect Mgmt0 IPv4 Address: 10.29.133.104

    Peer Fabric interconnect Mgmt0 IPv4 Netmask: 255.255.255.0

    Cluster IPv4 address          : 10.29.133.106

 

    Peer FI is IPv4 Cluster enabled. Please Provide Local Fabric Interconnect Mgmt0 IPv4 Address

 

  Physical Switch Mgmt0 IP address : 10.29.133.105

 

 

  Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no): yes

  Applying configuration. Please wait.

 

Configuration file – Ok

Cisco UCS Manager

Log into the Cisco UCS Manager environment by completing the following steps:

1.    Open a web browser and navigate to the Cisco UCS Manager Cluster IP address, for example https://10.29.133.106

2.    Click the “Launch UCS Manager” HTML link to open the Cisco UCS Manager web client.

3.    At the login prompt, enter “admin” as the username, and enter the administrative password that was set during the initial console configuration.

4.    Click No when prompted to enable Cisco Smart Call Home, this feature can be enabled at a later time.

Cisco UCS Configuration

Configure the following ports, settings, and policies in the Cisco UCS Manager interface prior to beginning the Cohesity DataPlatform installation.

Cisco UCS Firmware

Your Cisco UCS firmware version should be current as shipped from the factory, as documented in the Software Components section. This document is based on Cisco UCS infrastructure, Cisco UCS B-series bundle, and Cisco UCS C-Series bundle software versions 4.0(1c). If the firmware version of the Fabric Interconnects is older than this version, the firmware must be upgraded to match the requirements prior to completing any further steps. To upgrade the Cisco UCS Manager version, the Fabric Interconnect firmware, and the server bundles, refer to these instructions:

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-manager/GUI-User-Guides/Firmware-Mgmt/3-2/b_UCSM_GUI_Firmware_Management_Guide_3_2.html

NTP

To synchronize the Cisco UCS environment time to the NTP server, complete the following steps:

1.    In Cisco UCS Manager, click the Admin button on the left-hand side.

2.    In the navigation pane, select All > Time Zone Management, and click the carat next to Time Zone Management to expand it.

3.    Click Timezone.

4.    In the Properties pane, select the appropriate time zone in the Time Zone menu.

5.    Click Add NTP Server.

6.    Enter the NTP server IP address and click OK.

7.    Click OK.

8.    Click Save Changes and then click OK.

Uplink Ports

The Ethernet ports of a Cisco UCS Fabric Interconnect are all capable of performing several functions, such as network uplinks or server ports, and more. By default, all ports are unconfigured, and their function must be defined by the administrator. To define the specified ports to be used as network uplinks to the upstream network, complete the following steps:

1.    In Cisco UCS Manager, click the Equipment button on the left-hand side.

2.    Select Fabric Interconnects > Fabric Interconnect A > Fixed Module or Expansion Module as appropriate > Ethernet Ports.

3.    Select the ports that are to be uplink ports, right click them, and click Configure as Uplink Port.

4.    Click Yes to confirm the configuration, and click OK.

5.    Select Fabric Interconnects > Fabric Interconnect B > Fixed Module or Expansion Module as appropriate > Ethernet Ports.

6.    Select the ports that are to be uplink ports, right-click them, and click Configure as Uplink Port.

7.    Click Yes to confirm the configuration and click OK.

8.    Verify all the necessary ports are now configured as uplink ports, where their role is listed as “Network.”

Uplink Port Channels

If the Cisco UCS uplinks from one Fabric Interconnect are to be combined into a port channel or vPC, you must separately configure the port channels, which will use the previously configured uplink ports. To configure the necessary port channels in the Cisco UCS environment, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    Under LAN > LAN Cloud, click the carat to expand the Fabric A tree.

3.    Right-click Port Channels underneath Fabric A, then click Create Port Channel.

4.    Enter the port channel ID number as the unique ID of the port channel (this does not have to match the port-channel ID on the upstream switch).

5.    Enter the name of the port channel.

6.    Click Next.

7.    Click each port from Fabric Interconnect A that will participate in the port channel, and click the >> button to add them to the port channel.

8.    Click Finish.

9.    Click OK.

10.  Under LAN > LAN Cloud, click the carat to expand the Fabric B tree.

11.  Right-click Port Channels underneath Fabric B, then click Create Port Channel.

12.  Enter the port channel ID number as the unique ID of the port channel (this does not have to match the port-channel ID on the upstream switch).

13.  Enter the name of the port channel.

14.  Click Next.

15.  Click each port from Fabric Interconnect B that will participate in the port channel, and click the >> button to add them to the port channel.

16.  Click Finish.

17.  Click OK.

18.  Verify the necessary port channels have been created. It can take a few minutes for the newly formed port channels to converge and come online.

Server Ports

The Ethernet ports of a Cisco UCS Fabric Interconnect connected to the rack-mount servers, or to the blade chassis must be defined as server ports. When a server port is activated, the connected server or chassis will begin the discovery process shortly afterwards. Cisco UCS rack-mount servers and blade chassis are automatically numbered in Cisco UCS Manager in the order which they are first discovered. For this reason, it is important to configure the server ports sequentially in the order you wish the physical servers and/or chassis to appear within Cisco UCS Manager. For example, if you installed your servers in a cabinet or rack with server #1 on the bottom, counting up as you progress higher in the cabinet or rack, then you need to enable the server ports to the bottom-most server first, and enable them one-by-one as you move upward. You must wait until the server appears in the Equipment tab of Cisco UCS Manager before configuring the ports for the next server. The same numbering procedure applies to blade server chassis, although chassis and rack-mount server numbers are separate from each other.

Auto Configuration

A new feature in Cisco UCS Manager 3.1(3a) and later is Server Port Auto-Discovery, which automates the configuration of ports on the Fabric Interconnects as server ports when a Cisco UCS rack-mount server or blade chassis is connected to them. The firmware on the rack-mount servers or blade chassis Fabric Extenders must already be at version 3.1(3a) or later in order for this feature to function properly. Enabling this policy eliminates the manual steps of configuring each server port, however it does configure the servers in a somewhat random order. For example, the rack-mount server at the bottom of the stack, which you may refer to as server #1, and you may have plugged into port 1 of both Fabric Interconnects, could be discovered as server 2, or server 5, etc. In order to have fine control of the rack-mount server or chassis numbering and order, the manual configuration steps listed in the next section must be followed.

To configure automatic server port definition and discovery, complete the following steps:

1.    In Cisco UCS Manager, click the Equipment button on the left-hand side.

2.    In the navigation tree, under Policies, click Port Auto-Discovery Policy

3.    In the properties pane, set Auto Configure Server Port option to Enabled.

4.    Click Save Changes.

5.    Click OK.

6.    Wait for a brief period, until the rack-mount servers appear in the Equipment tab underneath Equipment > Rack Mounts > Servers, or the chassis appears underneath Equipment > Chassis.

Manual Configuration

To manually define the specified ports to be used as server ports, and have control over the numbering of the servers, complete the following steps:

1.    In Cisco UCS Manager, click the Equipment button on the left-hand side.

2.    Select Fabric Interconnects > Fabric Interconnect A > Fixed Module or Expansion Module as appropriate > Ethernet Ports.

3.    Select the first port that is to be a server port, right-click it, and click Configure as Server Port.

4.    Click Yes to confirm the configuration and click OK.

5.    Select Fabric Interconnects > Fabric Interconnect B > Fixed Module or Expansion Module as appropriate > Ethernet Ports.

6.    Select the matching port as chosen for Fabric Interconnect A that is to be a server port, right-click it, and click Configure as Server Port.

7.    Click Yes to confirm the configuration and click OK.

8.    Wait for a brief period, until the rack-mount server appears in the Equipment tab underneath Equipment > Rack Mounts > Servers, or the chassis appears underneath Equipment > Chassis.

9.    Repeat Steps 1-8 for each pair of server ports, until all rack-mount servers and chassis appear in the order desired in the Equipment tab.

Server Discovery

As previously described, when the server ports of the Fabric Interconnects are configured and active, the servers connected to those ports will begin a discovery process. During discovery, the servers’ internal hardware inventories are collected, along with their current firmware revisions. Before continuing with the process of associating the servers with their service profiles, wait for all of the servers to finish their discovery process and to show as unassociated servers that are powered off, with no errors.

To view the servers’ discovery status, complete the following steps:

1.    In Cisco UCS Manager, click the Equipment button on the left-hand side, and click Equipment in the top of the navigation tree on the left.

2.    In the properties pane, click the Servers tab.

3.    Click the Blade Servers or Rack-Mount Servers sub-tab as appropriate, and view the servers’ status in the Overall Status column.

Cisco UCS Organization

Cisco UCS Manager sub-organizations are created underneath the root level of the Cisco UCS hierarchy, which are used to contain all policies, pools, templates and service profiles used by the connected servers. Creating a sub-organization specifically for the Cohesity cluster prevents problems from overlapping settings across policies and pools. This arrangement also allows for organizational control using Role-Based Access Control (RBAC) and administrative locales within Cisco UCS Manager at a later time if desired. In this way, control can be granted to administrators of only the Cohesity specific elements of the Cisco UCS domain, separate from control of root level elements or elements in other sub-organizations.

To create a sub-organization for the Cohesity cluster, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Servers > Service Profiles, right-click root, then click Create Organization.

3.    Enter a name for the organization, for example “Cohesity” and optionally enter a description.

4.    Click OK.

Cisco UCS LAN Policies

VLANs

Names and IDs for the required VLANs must be defined in the Cisco UCS configuration page prior to the Cohesity installation. The VLANs listed in Cisco UCS must already be present on the upstream network, and the Cisco UCS FIs do not participate in VLAN Trunk Protocol (VTP).

To configure the VLAN(s) required for the installation, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath LAN > LAN Cloud, right-click VLANs, then click Create VLANs.

3.    Enter a VLAN name which describes the VLAN purpose.

4.    Leave the Multicast Policy Name as <not set>.

5.    Choose the radio button for Common/Global.

6.    Enter the VLAN ID for this VLAN as defined in the upstream switches.

7.    Choose the radio button for Sharing Type: None.

8.    Click OK.

Table 21and Figure 11 detail the VLANs configured for HyperFlex:

Table 21  Cisco UCS VLANs

Cisco UCS VLANs

QoS System Classes

By default, Cohesity clusters do not utilize Quality of Service (QoS) policies in their service profiles, and instead place all network traffic into the default “Best-Effort” class. Notably, Cisco HyperFlex clusters are deployed using QoS and a specific configuration for the UCS QoS System Classes is set during installation. Changes to the UCS QoS System Classes require a reboot of both Fabric Interconnects. For this reason, if a single UCS domain is intended to contain both Cisco HyperFlex clusters and Cohesity, it is highly recommended to first deploy the Cisco HyperFlex cluster(s). This allows the correct QoS system classes to be set without interrupting service to an existing workload, afterwards Cohesity and other systems can be deployed without any additional impacts. 

Management IP Address Pool

A Cisco UCS Management IP Address Pool must be populated with a block of IP addresses. These IP addresses are assigned to the Cisco Integrated Management Controller (CIMC) interface of the rack mount and blade servers that are managed in the Cisco UCS domain. The IP addresses are the communication endpoints for various functions, such as remote KVM, virtual media, Serial over LAN (SoL), and Intelligent Platform Management Interface (IPMI) for each rack mount or blade server. Therefore, a minimum of one IP address per physical server in the domain must be provided. The IP addresses are considered to be an “out-of-band” address, meaning that the communication pathway uses the Fabric Interconnects’ mgmt0 ports, which answer ARP requests for the management addresses. Because of this arrangement, the IP addresses in this pool must be in the same IP subnet as the IP addresses assigned to the Fabric Interconnects’ mgmt0 ports.

To create the management IP address pool, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath Pools > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click IP Pools, then click Create IP Pool.

4.    Enter a name for the IP address pool, such as “Cohesity”, and optionally enter a description.

5.    Click the radio button for Assignment Order: Sequential in order to apply the addresses to the servers in sequence. Choosing Default will result in a random assignment order.

6.    Click Next.

7.    Click the Add button near the bottom to add a block of IPv4 addresses.

8.    Enter the first IP address of the pool in the From: field.

9.    Enter the size of the address pool in the Size: field.

10.  Enter the correct values for the Subnet Mask, Default Gateway, and Primary and Secondary DNS servers.

11.  Click OK.

12.  Click Next.

13.  In most cases, a pool of IPv6 addresses is not necessary, therefore click Finish.

Management IP Address Pool

MAC Address Pools

One of the core benefits of the Cisco UCS and Virtual Interface Card (VIC) technology is the assignment of the personality of the card via Cisco UCS Service Profiles. The number of virtual NIC (vNIC) interfaces, their VLAN associations, MAC addresses, QoS policies and more are all applied dynamically as part of the service profile association process. Media Access Control (MAC) addresses use 6 bytes of data as a unique address to identify the interface on the layer 2 network. All devices are assigned a unique MAC address, which is ultimately used for all data transmission and reception. The Cisco UCS and VIC technology picks a MAC address from a pool of addresses, and assigns it to each vNIC defined in the service profile when that service profile is created.

Best practices mandate that MAC addresses used for Cisco UCS domains use 00:25:B5 as the first three bytes, which is one of the Organizationally Unique Identifiers (OUI) registered to Cisco Systems, Inc. The remaining 3 bytes can be manually set. The fourth byte (e.g. 00:25:B5:xx) is often used to identify a specific UCS domain, meanwhile the fifth byte is often set to correlate to the Cisco UCS fabric and the vNIC placement order. Finally, the last byte is incremented upward from the starting value defined, according to the number of MAC addresses created in the pool. To avoid overlaps, when you define these values you must ensure that the MAC address pools are unique for each UCS domain installed in the same layer 2 network.

Cohesity servers running inside the Cisco UCS domain require two vNICs, one in the A side fabric, and one in the B side fabric. To make identification and troubleshooting easier, it is recommended to create two MAC address pools; one for the A side fabric vNICs, and a second for the B side fabric vNICs, each with a unique identifier in the fifth byte.

To create the MAC address pools, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath Pools > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click MAC Pools, then click Create MAC Pool.

4.    Enter a name for the MAC address pool, such as “cohesity-mac-a”, and optionally enter a description.

5.    Click the radio button for Assignment Order: Sequential in order to apply the addresses to the servers in sequence. Choosing Default will result in a random assignment order.

6.    Click Next.

7.    Click the Add button near the bottom to add a block of MAC addresses.

8.    Modify the values in the 4^th byte and 5^th byte as necessary in the First MAC Address field. For example, change the field to read “00:25:B5:C0:A1:00”

9.    Enter the size of the address pool in the Size: field.

10.  Click OK.

11.  Click Finish.

12.  Repeat steps 1-11 to create any additional MAC address pools required, for example a second pool for the B side vNICs.

Table 22details an example of MAC Address Pools configured for Cohesity and their association to the vNIC templates created afterward:

Table 22  MAC Address Pools

MAC Address Pools

Network Control Policies

Cisco UCS Network Control Policies control various aspects of the behavior of vNICs defined in the Cisco UCS Service Profiles. Settings controlled include enablement of Cisco Discovery Protocol (CDP), MAC address registration, MAC address forging, and the action taken on the vNIC status if the Cisco UCS network uplinks are failed. Of these settings, the most important for the Cohesity DataPlatform is the setting to mark the vNICs as Link Down if there is a failure of all the uplinks from that Fabric Interconnect. This helps ensure that the OS level bonding in the Cohesity nodes will correctly fail over to the other fabric if all uplinks from one FI are lost.

To configure the Network Control Policy, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Network Control Policies, then click Create Network Control Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Click the radio button to set CDP: Enabled.

6.    Make sure the setting for Action on Uplink Fail is set to Link Down.

7.    All other settings can be left at their defaults.

8.    Click OK.

Table 23details the Network Control Policy configured for Cohesity, and the assignment to the vNIC templates created:

Table 23  Network Control Policy

Network Control Policy

vNIC Templates

Cisco UCS Manager has a feature to configure vNIC templates, which can be used to simplify and speed up configuration efforts. VNIC templates are referenced in service profiles and LAN connectivity policies, versus configuring the same vNICs individually in each service profile, or service profile template. VNIC templates contain all the configuration elements that make up a vNIC, including VLAN assignment, MAC address pool selection, fabric A or B assignment, fabric failover, MTU, QoS policy, Network Control Policy, and more. Templates are created as either initial templates, or updating templates. Updating templates retain a link between the parent template and the child object, therefore when changes are made to the template, the changes are propagated to all remaining linked child objects. An additional feature named “vNIC Redundancy” allows vNICs to be configured in pairs, so that the settings of one vNIC template, designated as a primary template, will automatically be applied to a configured secondary template. For all Cohesity vNIC templates, the “A” side vNIC template is configured as a primary template, and the related “B” side vNIC template is a secondary. In each case, the only configuration difference between the two templates is which fabric they are configured to connect through.

To create the vNIC templates, complete the following steps:

1.     In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click vNIC Templates, then click Create vNIC Template.

4.    Enter a name for the template, and optionally enter a description.

5.    Click the radio button for Fabric ID: Fabric A, and ensure the checkbox for Enable Failover is left unchecked.

6.    Click the radio button for Redundancy Type: Primary Template. Leave the Peer Redundancy Template as <not set>.

7.    Leave the Target checkbox for Adapter as checked, and for VM as unchecked.

8.    Click the radio button for Template Type: Updating Template.

9.    In the list of VLANs, click the checkbox next to the VLAN which was created for Cohesity cluster traffic in order to select it, and click the radio button on the right for Native VLAN in order to pass the traffic without VLAN ID tags.

10.  Scroll down in the window, ensure that the CDN source is left as vNIC Name, and the MTU is set to 1500.

11.  Choose the MAC Address Pool created earlier for the A side fabric for this vNIC.

12.  Choose the Network Control Policy created earlier for this Cohesity sub-organization.

13.  Click OK.

14.  Repeat steps 1-13, but do so for the B side vNIC template, which requires the following changes:

a.     Give the template a unique name for the B side template.

b.     Choose Fabric B for the Fabric ID.

c.     Choose Secondary Template for the Redundancy Type.

d.     Choose the vNIC template just created earlier as the Peer Redundancy Template.

e.     Choose the MAC Address Pool created earlier for the B side fabric.

The following tables detail the initial settings in each of the vNIC templates created for the Cohesity DataPlatform:

Table 24  vNIC Template cohesity-vnic-a

Table 25  vNIC Template cohesity-vnic-b

LAN Connectivity Policies

Cisco UCS Manager has a feature for LAN Connectivity Policies, which aggregates all of the vNICs or vNIC templates desired for a service profile configuration into a single policy definition. This simplifies configuration efforts by defining a collection of vNICs or vNIC templates once, and using that policy in the service profiles or service profile templates.

To create the LAN Connectivity Policy, complete the following steps:

1.    In Cisco UCS Manager, click the LAN button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click LAN Connectivity Policies, then click Create LAN Connectivity Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Click the Add button near the bottom to add a VNIC.

6.    Enter a name for the vNIC being added, for example vNIC0.

7.    Click the Use vNIC Template checkbox.

8.    In the vNIC Template drop-down box, choose the A side vNIC template created earlier.

9.    Click the Redundancy Pair checkbox.

10.  In the Peer Name field, enter a name for the redundant vNIC, for example vNIC1.

11.  In the Adapter Policy drop-down box, choose the Linux policy.

12.  Click OK.

13.  Click OK.

Table 26 details the LAN Connectivity Policy configured for Cohesity:

Table 26  LAN Connectivity Policy

Cisco UCS Server Policies

BIOS Policies

Cisco M5 generation servers no longer use pre-defined BIOS setting defaults derived from Cisco UCS Manager, instead the servers have default BIOS tokens set from the factory. The current default token settings can be viewed at the following website: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-manager/Reference-Docs/Server-BIOS-Tokens/4-0/b_UCS_BIOS_Tokens_Guide_4_0.html

A BIOS policy must be created to modify the setting of M5 generation servers to enable Serial over LAN communication, which can be used during troubleshooting efforts.

To configure the BIOS policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click BIOS Policies, then click Create BIOS Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Click OK.

6.    Click the name of the BIOS Policy which was just created.

7.    In the right-hand pane of the Cisco UCS Manager screen, click the Advanced tab.

8.    Click the Serial Port sub-tab.

9.    Change the Serial Port A enable Value to Enabled in the drop-down list.

10.  Click the Server Management tab at the top of the pane.

11.  Change the Console Redirection BIOS setting Value to Serial Port A in the drop-down list.

12.  Click Save Changes.

Table 27 details the BIOS Policy configured for Cohesity:

Table 27  BIOS Policy

Boot Policies

Cisco UCS Boot Policies define the boot devices used by blade and rack-mount servers, and the order that they are attempted to boot from. Cisco UCS C-Series M5 generation rack-mount servers which run the Cohesity DataPlatform have their Linux operating system installed to a pair of internal M.2 SSD boot drives, therefore they require a unique boot policy defining that the servers should boot from that location. In addition, a local CD/DVD boot option is included to allow the server to search for the installation ISO media during the Cohesity installation steps.

To configure the Boot Policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Boot Policies, then click Create Boot Policy.

4.    Enter a name for the template, and optionally enter a description.

5.    Leave all settings at their defaults, ensuring the Boot Mode option is set to Legacy.

6.    In the Boot Order area, click the + symbol next to Local Devices to expand the list.

7.    Click the blue link for “Add CD/DVD”, you will see this selection added to the boot order.

8.    Click the blue link for “Add Embedded Local Disk”.

9.    In the pop-up window, click the radio button for Any, then click OK.

10.  Click OK.

 

Figure 15 details the Cohesity Boot Policy:

Cisco UCS Cohesity Boot Policy

Host Firmware Packages

Cisco UCS Host Firmware Packages represent one of the most powerful features of the Cisco UCS platform; the ability to control the firmware revision of all the managed blades and rack-mount servers via a policy specified in the service profile. Host Firmware Packages are defined and referenced in the service profiles. Once a service profile is associated to a server, the firmware of all the components defined in the Host Firmware Package are automatically upgraded or downgraded to match the package. A Host Firmware Package is created for the Cohesity nodes, which uses the simple package definition method, applying firmware revisions to all components that matches a specific Cisco UCS firmware bundle, versus defining the firmware revisions part by part.

To configure the Host Firmware Package, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Host Firmware Packages, then click Create Host Firmware Package.

4.    Enter a name for the package, and optionally enter a description.

5.    Click the radio button for Simple package selection.

6.    In the Blade Package and Rack Package drop-down lists, choose the package version that matches the desires firmware version. In most cases, the version chosen would match the currently running Cisco UCS Manager and Fabric Interconnect versions, for example, 4.0(1c)B, and 4.0(1c)C.

7.    Choose a Service Pack revision if applicable.

8.    In the Excluded Components list, make sure all checkboxes are unchecked.

9.    Click OK.

The following figure details the Host Firmware Package used for Cohesity:

Cohesity Host Firmware Package

Local Disk Configuration Policies

Cisco UCS Local Disk Configuration Policies are used to define the configuration of disks installed locally within each blade or rack-mount server, most often to configure Redundant Array of Independent/Inexpensive Disks (RAID levels) when multiple disks are present for data protection. Since Cohesity converged nodes providing storage resources utilize software defined storage, the nodes do not require a local disk configuration to be set. Therefore, a simple policy which allows any local disk configuration is all that is required.

To configure the Local Disk Configuration Policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Local Disk Config Policies, then click Create Local Disk Configuration Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Leave all options at their default settings, ensuring the Mode drop-down list is set to “Any Configuration”.

6.    Click OK.

Figure 17 detail the Local Disk Configuration Policies configured by the HyperFlex installer:

Cohesity Local Disk Configuration Policy

Maintenance Policies

Cisco UCS Maintenance Policies define the behavior of the attached blades and rack-mount servers when changes are made to the associated service profiles. The default Cisco UCS Maintenance Policy setting is “Immediate” meaning that any change to a service profile that requires a reboot of the physical server will result in an immediate reboot of that server. The Cisco best practice is to use a Maintenance Policy set to “user-ack”, which requires a secondary acknowledgement by a user with the appropriate rights within Cisco UCS Manager, before the server is rebooted to apply the changes. In addition, the On Next Boot setting is enabled, which will automatically apply changes the next time the server is rebooted, without any secondary acknowledgement.

To configure the Maintenance Policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Maintenance Policies, then click Create Maintenance Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Click the radio button for Reboot Policy: User Ack.

6.    Check the checkbox for On Next Boot.

7.    Click OK.

Figure 18 details the Maintenance Policy configured for Cohesity:

Cisco UCS Maintenance Policy

Serial over LAN Policies

Cisco UCS Serial over LAN (SoL) Policies enable console output which is sent to the serial port of the server, to be accessible via the LAN. For many Linux based operating systems, the local serial port can be configured as a local console, where users can watch the system boot, and communicate with the system command prompt interactively. Since many servers do not have physical serial ports, and often administrators are working remotely, the ability to send and receive that traffic via the LAN is very helpful. Interaction with SoL can be initiated by connecting to the CIMC IP address configured by UCS Manager using SSH, and entering valid Cisco UCS manager credentials.

To configure the Serial Over LAN Policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click Serial Over LAN Policies, then click Create Serial Over LAN Policy.

4.    Enter a name for the policy, and optionally enter a description.

5.    Select the radio button for Serial Over Lan State: Enable

6.    Select 115200 from the Speed drop-down list.

7.    Click OK.

Figure 19 details the SoL Policy configured for Cohesity:

Cisco UCS Serial over LAN Policy

IPMI Access Profile

Cisco UCS Intelligent Platform Management Interface (IPMI) Policies allow for remote interactions with physical hardware resources via the LAN, such as querying power states or forcing servers to power on or off. The Cohesity DataPlatform requires IPMI access to each node, and asks for the IPMI addresses and credentials during the installation. Consequently, and IPMI policy is required to enable the functionality via the CIMC interfaces, and to define the username and password which has access to the IPMI commands.

To configure the IPMI Policy, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Policies > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click IPMI Access Profiles, then click Create IPMI Access Profile.

4.    Enter a name for the policy, and optionally enter a description.

5.    Click the radio button for IPMI Over LAN: Enable.

6.    Click Add to create a user.

7.    Enter the username.

8.    Enter and confirm the desired password.

9.    Click the radio button for Role: Admin.

10.  Click OK.

11.  Click OK.

Figure 19 details the IPMI configured for Cohesity:

Cisco UCS IPMI Policy

Cisco UCS Service Profile Templates

Cisco UCS Manager has a feature to configure service profile templates, which can be used to simplify and speed up configuration efforts when the same configuration needs to be applied to multiple servers. Service profile templates are used to spawn multiple service profile copies to associate with a group of servers, versus configuring the same service profile manually each time it is needed. Service profile templates contain all the configuration elements that make up a service profile, including vNICs, vHBAs, local disk configurations, boot policies, host firmware packages, BIOS policies and more. Templates are created as either initial templates, or updating templates. Updating templates retain a link between the parent template and the child object, therefore when changes are made to the template, the changes are propagated to all remaining linked child objects.

To configure the Service Profile Template, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Service Profile Templates > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click the sub-org name, then click Create Service Profile Template.

4.    Enter a name for the template.

5.    Click the radio button for Type: Updating Template.

6.    In the UUID Assignment drop-down list, select Hardware Default.

7.    Click Next.

8.    In the Storage Provisioning section, click the Local Disk Configuration Policy tab, then in the drop-down list below, select the Local Disk Configuration Policy which was created for this template earlier.

9.    Click Next.

10.  In the Networking section, click the radio button for Use Connectivity Policy, then in the drop-down list below, select the LAN Connectivity Policy which was created for this template earlier.

11.  Click Next.

12.  In the SAN Connectivity section, click the radio button for No vHBAs, then click Next.

13.  In the Zoning section, no changes are required, click Next.

14.  In the vNIC/vHBA Placement section, no changes are required, click Next.

15.  In the vMedia Policy section, no changes are required, click Next.

16.  In the Server Boot Order section, in the Boot Policy drop-down list, select the Boot Policy which was created for this template earlier.

17.  Click Next.

18.  In the Maintenance Policy section, in the Maintenance Policy drop-down list, select the Maintenance Policy which was created for this template earlier.

19.  Click Next.

20.  In the Server Assignment section, leave the Pool Assignment set to Assign Later, and select the radio button for the desired power state to Up.

21.  Click the + button next to Firmware Management to expand the section. In the Host Firmware Package drop-down list, select the Host Firmware Package which was created for this template earlier.

22.  Click Next.

23.  In the Operation Policies section, click the + button next to BIOS Configuration to expand the section. In the BIOS Policy drop-down list, select the BIOS Policy which was created for this template earlier.

24.  Click the + button next to External IPMI Management Configuration to expand the section. In the IPMI Access Profile drop-down list, select the IPMI Access Profile which was created for this template earlier.

25.  In the SoL Configuration Profile drop-down list, select the Serial Over LAN Policy which was created for this template earlier.

26.  Click the + button next to Management IP Address to expand the section. Click the Outband IPv4 tab, then in the Management IP Address Policy drop-down list, select the Management IP Address Pool which was created for this template earlier.

27.  Click Finish.

The following table details the service profile template configured for the Cohesity DataPlatform nodes:

Table 28  Cisco UCS Service Profile Template Settings and Values

Create Service Profiles

When a Cisco UCS Service Profile Template has been created, individual Service Profiles for each Cohesity node can be created from the template. The unique identifying characteristics of the service profile, such as MAC addresses or IP addresses, are drawn from the pools and the configurations are set according the policies, when the service profile is created. By basing the service profiles on a template, all of the service profiles will have identical configurations. Because the service profiles are based on an updating template, if any errors are found, or changes need to be made to all of the servers, the changes can be made in the parent template, and all child profiles will inherit the change.

To configure the Service Profiles from the Template, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Service Profile Templates > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Right-click the Service Profile Template, then click Create Service Profiles From Template.

4.    Enter a naming prefix, which will be applied to all of the spawned service profiles, for example “Cohesity-node-“

5.    Enter the starting number for the number to be appended to the name prefix just entered.

6.    Enter the number of service profiles to create from this template.

7.    Click OK.

Service Profile Association

When a Cisco UCS Service Profile has been created, it must be associated with a physical hardware asset in order to take effect. Service profile association requires the rack-mount servers or blade servers in the blade chassis to be present, fully discovered, and not currently associated with any other service profiles. Automatic assignment of service profiles can be done through the use of server pools and auto-discovery, but that configuration is not the recommended method for this paper, and therefore not covered in this document. Once the service profile association is initiated, all of the configuration elements and identities are applied to the server hardware, including storage, networking, policies and firmware upgrades. At the conclusion of the association process, the server will be ready for use, but with no operating system installed.

To associate the Service Profiles to the Cohesity node servers, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Service Profiles > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Click the first Service Profile you wish to associate, then in the right-hand pane, click the blue link for “Change Service Profile Association.”

4.    In the Server Assignment drop-down list, choose “Select existing Server.”

5.    Ensure the radio button for Available Servers is selected, in the list below you should see the connected and discovered Cisco C240 M5 LFF nodes which have not yet been associated with a service profile.

6.    Select the radio button next to the first server to associate, then click OK.

7.    Repeat steps 1-6 for each remaining service profile, choosing a subsequent C240 M5 LFF node to associate with.

As previously described, when the service profile association is started, there are many activities that must take place to finalize the configuration of the server. The process can take some time to complete, especially if there are significant firmware updates to perform in order to comply with the policy. Before continuing with the Cohesity installation processes, wait for all of the servers to finish their association process and to show an overall status of OK, with no errors.

To view the servers’ discovery status, complete the following steps:

1.    In Cisco UCS Manager, click the Equipment button on the left-hand side, and click Equipment in the top of the navigation tree on the left.

2.    In the properties pane, click the Servers tab.

3.    Click the Blade Servers or Rack-Mount Servers sub-tab as appropriate, and view the servers’ status in the Overall Status column.

Cohesity Installation

Cohesity DataPlatform is installed in three phases; first is the initial software installation to all of the Cohesity nodes, followed by the initial network setup of a single node in order to access the Cohesity configuration webpage, and finally the initial Cohesity cluster configuration, which is done from the aforementioned webpage.

Cohesity Software Installation

The installation of Cohesity DataPlatform software is done via a bootable DVD ISO image file. Each node is booted from this image file, which will automate the process of installing the underlying Linux operating system, copy the Cohesity software packages, and prepare the nodes for the initial setup of the Cohesity cluster.

To install the Cohesity software on each Cisco UCS C240 M5 node, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Service Profiles > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Each Cohesity node will have its own service profile, for example: Cohesity-node-1. Right-click the first service profile and click KVM Console. The remote KVM console will open in a new browser tab. Accept any SSL errors or alerts, then click the link to launch the KVM console.

4.    In the remote KVM tab, click the Virtual Media button in the top right-hand corner of the screen, then click Activate Virtual Devices.

5.    In the remote KVM tab, click the Virtual Media button in the top right-hand corner of the screen, then click the CD/DVD option.

6.    Click Choose File, browse for the Cohesity ISO installer file, and click Open.

7.    Click Map Drive.

8.    In the remote KVM tab, click the Server Actions button in the top right-hand corner of the screen, the click Reset.

9.    Click OK.

10.  Choose the Power Cycle option, then click OK.

11.  Click OK.

12.  Observe the server going through the POST process until the following screen is seen. When it appears, press the F6 key to enter into the boot device selection menu.

13.  Select Cisco vKVM-mapped vDVD1.24, then press Enter.

14.  The server will boot from the remote KVM mapped Cohesity ISO installer and display the following screen:

15.  Allow the automatic timer to count down from 120 seconds, or press Enter.

16.  The Cohesity installer will now automatically perform the installation to the boot media. Installation time takes approximately 70-75 minutes. Once the new server has completed the installation, the server will reboot and it will be waiting at the console login prompt screen seen below.

17.  In the remote KVM tab, click the Exit button, then click Yes.

18.  Repeat steps 3-17 for each additional Cohesity node being installed.

Cohesity First Node Configuration

In order to perform the initial cluster setup, the first node of the Cohesity cluster must be accessible via the network, so that the administrator performing the configuration can access the Cohesity configuration webpage running on that node. Cohesity nodes will automatically configure themselves with IPv6 link-local addresses, and use these addresses to discover each other on the same subnet. These IPv6 addresses can also be used to perform the initial configuration via the webpage. However, many environments are not configured to use IPv6, therefore it is more common to use IPv4 addresses to perform the initial configuration. To use IPv4 addresses, the first node must be manually configured with an IPv4 address, so that the webpage is accessible to the administrator’s client computer.

To manually configure the first Cohesity node’s IPv4 addressing, complete the following steps:

1.    In Cisco UCS Manager, click the Servers button on the left-hand side.

2.    In the tree hierarchy, underneath Service Profiles > root > Sub-Organizations, click the carat next to the name of the sub-organization created for Cohesity to expand it.

3.    Each Cohesity node will have its own service profile, for example: Cohesity-node-1. Right-click the first service profile and click KVM Console. The remote KVM console will open in a new browser tab. Accept any SSL errors or alerts, then click the link to launch the KVM console.

4.    When the node’s local login prompt appears, login with the following credentials:

a.     Username: cohesity

b.     Password: Cohe$1ty

5.    Edit the configuration file for the bond0 interface using a text editor, such as vi, entering the following lines, and their corresponding values:

sudo vi /etc/sysconfig/network-scripts/ifcfg-bond0

 

IPADDR=<ip>

NETMASK=<mask>

GATEWAY=<gw>

 

6.    Restart the network services of the node:

sudo systemctl restart network

7.    Test the network is working properly by pinging the default gateway. You can also verify the IP address configuration by issuing the following command:

ip addr

8.    Log out of the node:

exit

9.    In the remote KVM tab, click the Exit button, then click Yes.

Cohesity Cluster Setup

The initial setup of the Cohesity cluster is done via the configuration webpage, which is now accessible on the first node, at the IP address which was configured in the previous steps. Prior to beginning the initial cluster configuration, ensure that all of the Cohesity nodes which are to be included in the cluster have completed their initial software installation, and are fully booted. Additionally, ensure that all of the necessary IP addresses for all of the interfaces are known and assigned, and the DNS round-robin entries have been created.

To perform the Cohesity initial cluster configuration, complete the following steps:

1.    In a web browser, navigate to the IP address of the first Cohesity node, which was just configured in the previous steps. For example: http://10.29.133.227

2.    Accept any SSL warnings or errors due to the default self-signed certificate on the server, and proceed to the Cohesity Dashboard login screen.

3.    Log into the Cohesity Dashboard webpage using the credentials below:

a.     Username: admin

b.     Password: admin

4.    The Start Initial Cluster Setup screen appears, make sure that the number of nodes detected matches the number of servers you intend to install for this cluster. Click Get Started.

5.    Select the nodes to add to this initial cluster, or click the link to Select All Available in the upper right-hand corner, then click Select Nodes.

6.    For each server, enter the IP address which will be assigned to the Linux OS into the IP field.

7.    For each server, enter the IPMI address (CIMC Management IP Address) in the IPMI IP field.

8.    Click Continue to Cluster Settings.

9.    Enter the desired name of the cluster and the DNS domain suffix.

10.  Enter the gateway IP address and subnet mask for the IP addresses being assigned to the OS and VIPs of the nodes.

11.  Enter the subnet mask and gateway address of the subnet where the nodes’ IPMI interfaces are configured.

12.  Enter the username and password for IPMI access, to match the username and password configured in the Cisco UCS Manager IPMI Access Profile, which was configured earlier.

13.  Enter the required NTP server addresses, separated by commas.

14.  Enter the hostname for the Cohesity cluster partition. This hostname typically matches the name of the cluster.

15.  Enter the starting IP address for the VIP addresses that are being assigned to the Cohesity nodes. These IP addresses are the addresses which are resolved by DNS round-robin for the cluster, not the individual node IP addresses. For example: 10.29.133.231

16.  Enter the last octet value for the end of the VIP range, for example: 234

17.  Click Add VIP or VIP Range.

18.  Optionally choose to enable systemwide encryption by toggling the switch. Encryption can be enabled at a later time for each separately configured storage domain. Because the latter option provides more flexibility, it is not recommended to enable systemwide encryption at this time, as this choice cannot be reversed.

19.  Click Create Cluster.

20.  Observe the cluster creation status. Additional details can be viewed by clicking Show Details.

21.  The status will appear to pause at 98-99% for a significant period of time while formatting the disks. The time to format nodes with 10 TB capacity disks will be longer than the time for nodes with 4 TB capacity disks. The time to create the cluster for a 4-node cluster with 10 TB disks is approximately 40 minutes.

22.  After the setup completes, the web services will restart. After a few minutes, the Cohesity Dashboard webpage for the cluster will be available at the DNS round-robin address configured for the cluster. For example: https://chx-cluster01

Cohesity Dashboard

The primary management interface for the Cohesity DataPlatform is the embedded Cohesity Dashboard web interface. All cluster configurations, policies, jobs, and activities can be created, modified and monitored via the Cohesity Dashboard.

To log into the Cohesity Dashboard, complete the following steps:

1.    In a web browser, navigate to the DNS round-robin name of the Cohesity cluster, which was just set up in the previous steps. For example: https://chx-cluster01

2.    Accept any SSL warnings or errors due to the default self-signed certificate on the server, and proceed to the Cohesity Dashboard login screen.

3.    Log into the Cohesity Dashboard webpage using the credentials below:

a.     Username: admin

b.     Password: admin

4.    Accept the End User Licensing agreement by clicking Accept.

5.    Enter a valid Cohesity license code.

6.    Click Submit.

Cluster Configuration

After the initial Cohesity cluster setup has completed, the system is operating with a preset collection of default settings. In order to tailor the cluster to your individual needs, these various settings should be modified.

Partitions

Conceptually, a Cohesity cluster is a collection of nodes running the Cohesity software, which provide storage resources. A Cohesity cluster contains a single partition, therefore the partition is synonymous to the overall cluster. There are some settings which are modified as an overall cluster, and some advanced settings that can be configured at the partition level, such as custom host mappings, or VLANs. These settings are not required to be modified in the example configuration detailed in this document, and in most circumstances, the default partition, named “DefaultPartition” can be left unmodified.

Storage Domains

Storage Domains represent a subdivision of the default partition, and many settings can be modified at the Storage Domain level. In particular, settings for deduplication, compression, encryption, and data replication can all be controlled individually for each Storage Domain that is created. Protection Jobs and Views all target a specific Storage Domain in their configurations. This arrangement provides additional flexibility, because through the use of multiple domains, which are then targeted by different jobs and workloads, each of them can be tailored to meet the requirements of that job or workload.

To modify the default Storage Domain of the Cohesity cluster, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Cluster.

3.    Click the Storage Domains tab.

4.    Click the ellipses to the far right-hand side of the line item of the “DefaultStorageDomain”, then click Edit.

5.    Modify the name of the domain to one which helps to identify the usage and/or settings of this domain, for example, “domain_rf2_id_ic” which indicates a domain using a data replication factor of 2 for redundancy, plus inline deduplication, and inline compression.

6.    Modify the settings of this domain for deduplication, compression, encryption, quotas, and failure tolerance as required.

7.    Click Update Storage Domain.

To create additional Storage Domains with unique settings from the default domain, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Cluster.

3.    Click the Storage Domains tab.

4.    Click Add Storage Domain.

5.    Enter the name of the domain, choosing one which helps to identify the usage and/or settings of this domain, for example, “domain_ec2_id_ic” which indicates a domain using erasure coding with 2 stripes for redundancy, plus inline deduplication, and inline compression.

6.    Modify the settings of this domain for deduplication, compression, encryption, quotas, and failure tolerance as required.

7.    Click Create Storage Domain.

Time zone

By default, a newly installed Cohesity cluster operates in the UMT (GMT+0) time zone. Organizations have many different standards for which time zone their hardware is configured to operate in. Some choose to have all hardware remain in UMT, others have all hardware operate in a single time zone regardless of physical location, meanwhile many always choose the local time zone of the hardware’s physical location. Reliable NTP servers are required and defined during the cluster installation. Ensure that the NTP servers listed are accessible from the network where the Cohesity cluster is installed.

To modify the time zone of the Cohesity cluster, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Admin menu at the top of the screen, click Cluster Settings.

3.    Click the link labeled “Change Time zone”.

4.    From the drop-down list, select the appropriate time zone for this cluster.

5.    Click Save.

Security

A newly installed Cohesity cluster has a single administrative user named “admin” with a default password. No additional external authentication sources are configured during the installation. At a minimum, the default admin user’s password should be modified away from the default.

Active Directory

Integration with Microsoft Active Directory allows for Active Directory user accounts to log into the Cohesity cluster to administer and use the system, plus it enables additional options to be selected and modified when creating Views that use the SMB protocol.

To join the Cohesity cluster to an Active Directory domain, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Admin menu at the top of the screen, click Access Management.

3.    Click the Active Directory tab.

4.    Click the link for Join Domain.

5.    Enter the Active Directory domain name.

6.    Enter a username and password for a user with administrative rights to join computers to the Active Directory domain.

7.    Optionally, enter a specific Organizational Unit where the computer account should be located in the Active Directory hierarchy.

8.    The Cohesity cluster name will automatically be listed as the machine account to be created. As long as the DNS round-robin records have been properly created prior to the Cohesity cluster installation, this is the only machine account name that is necessary.

9.    Click the Add Active Directory button.

 

Users and Roles

Additional local or Active Directory users can be created to allow them to log into the Cohesity system, and perform tasks according to the roles assigned to their account, which are defined in the cluster.

To add an authorized user to the Cohesity cluster, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Admin menu at the top of the screen, click Access Management.

3.    Click Add Users/Groups.

4.    Select the radio button for either a Local User or an Active Directory User & Groups.

5.    For a local user, enter the username, email address, password, and select a Role from the drop-down list.

6.    For an Active Directory User or Group, select the Active Directory Domain from the drop-down list, search for and select either the AD user or group you wish to add, then select a Role from the drop-down list.

7.    Click Add.

Passwords

Prior to changing the default System Admin account password, it is highly recommended to create at least one additional local, Active Directory, or LDAP user account with the Admin Role as outlined above. Using this secondary administrative account to make the password change ensures that administrators do not accidentally get locked out of the cluster due to a faulty password change.

To change the default System Admin password, complete the following steps:

1.    Log into the Cohesity Dashboard web page as a user with the Admin Role.

2.    From the Admin menu at the top of the screen, click Cluster Settings.

3.    Toggle the radio switch for “Change System Admin Password”.

4.    Enter and confirm the new password for the local admin account.

5.    Click Save.

Sources

Cohesity can provide protection for multiple platforms, including virtual machines running across a variety of hypervisors, cloud-based virtual machines, bare-metal servers, Oracle and Microsoft SQL databases, plus direct protection of storage array volumes. Cohesity protection jobs are each configured to target specific sources, therefore prior to configuring the protection jobs the sources must be registered with the Cohesity cluster.

Hypervisor Source

Protection of a VMware ESXi based cluster is conducted via the managing VMware vCenter Server. Cisco HyperFlex clusters running on VMware ESXi hypervisors also use vCenter for management of the cluster. To configure protection of a Cisco HyperFlex ESXi based cluster, the managing vCenter server must be registered as a source for the protection jobs.

To configure a hypervisor source, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Sources.

3.    Click the Register button and from the drop-down list that appears, click Hypervisor.

4.    From the Hypervisor Source Type drop-down list, choose VMware: vCenter

5.    Enter the hostname or IP address of the vCenter server managing the Cisco HyperFlex cluster being protected, and an administrative username and password.

6.    Toggle the radio button on for the “Auto Cancel Backups if Datastore is running low on space” option, and enter a minimum value of free space for the datastore. If the datastore housing the VMs being snapped drops below this amount of free space, the job will be automatically cancelled.

7.    Click Register.

Storage Snapshot Provider

The Cohesity DataPlatform offers integration with storage-based snapshots, leveraging the native snapshot technologies built directly into the storage arrays, versus using the standard VMware based virtual machine snapshots. Cisco HyperFlex offers native storage-based snapshots, which provide space-efficient and crash-consistent snapshots taken by the underlying Cisco HyperFlex Distributed Filesystem, instead of standard VMware redo-log based snapshots. By using this integration via the Cisco HyperFlex API, the Cohesity protection jobs will take Cisco HyperFlex native snapshots instead of VMware snapshots. Cohesity protection jobs will always fall back to taking VMware native snapshots in case the HyperFlex native snapshot was not available. In order to use the Cisco HyperFlex API to create native snapshots, the Cisco HyperFlex cluster(s) must be registered as a Storage Snapshot Provider source.

In order for Cohesity Protection Jobs to always use native HX snapshots of the VMs running in the Cisco HyperFlex cluster(s), it is important that the VMs to be protected not have any existing standard VMware redo-log based snapshots. An existing VMware snapshot will prevent the creation of a subsequent HX native snapshot, and instead all snapshots taken by the Cohesity system will continue to be VMware snapshots. In this situation, prior to configuring Cohesity Protection Jobs it is recommended to delete all existing VMware snapshots from the virtual machines running in the Cisco HyperFlex cluster(s), which will be protected by Cohesity using the Storage Snapshot Provider integration. For VMs which already have existing HX native snapshots, no action is necessary, because subsequent snapshots taken by the Cohesity system using the Storage Snapshot Provider integration will continue to be HX native snapshots.

To configure Cisco HyperFlex as a Storage Snapshot Provider source, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Sources.

3.    Click the Register button, and from the drop-down list that appears, click Storage Snapshot Provider.

4.    From the Snapshot Storage Provider Type drop-down list, choose Storage Snapshot Provider: Hyperflex

5.    Enter the hostname or IP address of the roaming management interface of the Cisco HyperFlex cluster being protected, and an administrative username and password. This must be the roaming or floating management IP address, not the management IP address of any individual Cisco HyperFlex node.

6.    Click Register.

Remote Clusters

When multiple Cohesity clusters are available across the landscape, the Cohesity clusters can be registered with one another for both remote management, and more importantly, replication of backed up snapshots across the network. Utilizing this feature provides a secondary copy of the snapshots in a different physical cluster, which can be located in a standby datacenter used for disaster recovery. This secondary Cohesity cluster can have a standby VMware vCenter server registered as a source, and backups can quickly be restored to this recovery system in case a disaster is declared, or a planned failover to the secondary system is required. In order to replicate snapshots, the originating cluster (i.e. the cluster which captures the snapshot) must register the receiving cluster, and in return, the receiving cluster must register the originating cluster. A pairing is established between Storage Domains in the two clusters. A single Storage Domain in the originating cluster is paired with a single Storage Domain in the receiving cluster. A many-to-one pairing can be done only across multiple originating clusters, each one pairing a single Storage Domain, but all of them paired with the same receiving Storage Domain. Replication frequency and retention is controlled as part of the Cohesity policies, which each Protection Job is then assigned to follow.

To register remote clusters, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Remote Clusters.

3.    Click the Add Cluster button.

4.    Enter one or more of the Virtual IP addresses of the remote cluster nodes.

5.    Enter the username and password of a user with administrative rights in the remote cluster, then click Connect.

6.    Toggle the switches to enable Replication, and Remote Access if desired.

7.    Click the link to Add Storage Domain Pairing, and choose the local and remote Storage Domains to pair, then click Add.

8.    Optionally, select to enable load distribution, outbound compression, data encryption, transfer speed limits and overrides as needed.

9.    Click Create.

10.  Repeat steps 1 through 9 on the second Cohesity cluster, registering the cluster in the opposite direction of the first registration.

External Targets

In addition to replication of snapshots between multiple Cohesity clusters, Cohesity can be configured to copy snapshots to non-Cohesity locations, which is referred to as Archiving. Archival is controlled via the Cohesity policies in the same manner as Replication, and as with Replication, the External Target must be configured as a possible location for the archival task. Multiple types of External Targets are available, including Google, Amazon Web Services, Microsoft Azure, Network Attached Storage (NAS), and more. As such, this document will not describe all of the options available for configuration of these External Targets.

Policies

Cohesity policies define the backup types, frequency, retention periods, replication and archival options for protection jobs. Three standardized policies are included by default during the installation, however in many cases these options will need to be customized for your specific use. The default policies can be edited; however, it is recommended to make a copy of one of the default policies to use as a starting point. Alternatively, a new policy can be created from scratch.

To configure Cohesity policies, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Policy Manager.

3.    Click the Create Policy button.

a.     Alternatively, click the ellipses next to an existing policy and click Edit Policy.

b.     In addition, you may click the ellipses next to an existing policy and click Copy Policy. The subsequent policy may then be edited.

4.    Enter a name for the Policy being created or edited, and optionally enter a description.

5.    Toggle the DataLock radio button option if desired. DataLock will prevent snapshots from being removed from the cluster, even if the protection job is deleted, until the snapshot has exceeded its retention period. This allows for additional policy compliance and data protection against unintended deletion of snapshots.

6.    Configure the backup schedule to define the frequency of the job, along with the retention period for the snapshots to be kept.

7.    The default option is for every backup job since the first to be run as an incremental job, saving space and network bandwidth. The option can be modified to perform a full backup at regular intervals if desired.

8.    Extended retention can be configured to keep specific regular snapshots for longer retention periods than the standard retention schedule, if desired.

9.    Blackout periods can be configured, to prevent new runs of a job configured with this policy from starting if the current time is within the blackout period.

10.  Optional: If there are multiple Cohesity clusters available, the clusters can be registered with each other and then configured to replicate the snapshots being backed up. Configure replication of the backups to the remote Cohesity cluster if applicable.

11.  Optional: If External Targets are available, such as cloud providers, storage arrays and object-based S3 storage systems, these external targets can act as archival locations for off-site storage of Cohesity backups. Configure archival of the backups to the remote target if applicable.

12.  Click Create or Save as applicable.

Protection

Protection Jobs are configured in the Cohesity Dashboard to back up the configured sources, according to the Policies defined in the system. Each protection job obtains data from a single Source, operates according to the settings in a single Policy, and targets a single Storage Domain to store the snapshots. Because of this operational method, in order to back up virtual machines according to different schedules, or to target a different Storage Domain, a unique Protection Job must be created for each case. In the same way, backing up virtual machines from different sources, such as multiple Cisco HyperFlex clusters, or combinations of other sources, must be done in a distinct Protection Job per unique source.

During a Cohesity Protection Job, a new snapshot of the virtual machine is taken, and that snapshot is transferred via the network to the Storage Domain configured in the job. This constitutes a new incremental backup of that virtual machine. Once the snapshot is transferred, the snapshot of the virtual machine is deleted in the source hypervisor node. If the virtual machine being backed up was already running with an active snapshot, the new snapshot taken by Cohesity will be a child of the existing snap, then it will be deleted, coalescing the changes back into the existing snapshot level where the VM was already running. If the Storage Snapshot Provider integration with Cisco HyperFlex is enabled, then all of these snapshots will be taken as HX native snapshots. If the HX native snapshot attempt should fail, for example when an existing VMware standard redo-log snapshot exists, then the Protection Job will fall back to taking a standard VMware snapshot.

Of special note is a circumstance where a virtual machine has multiple snapshots, but the virtual machine has been reverted to a previous snapshot and is therefore not running as the most recent snapshot. Cohesity Protection Jobs will take the snapshot at the level where the VM is currently running, therefore, any changes contained in a child snapshot that is not the current running snapshot of the VM, will not be captured in the Cohesity backup. The existence of unused child snapshots will cause warnings during the execution of a Cohesity Protection Job, and such unused snapshots should be removed.

To create a Protection Job, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Protection Jobs.

3.    Click the Protect button, from the drop-down list that appears, click Virtual Server.

4.    Enter a name for the job, and optionally enter a description.

5.    Select a source for the job from the drop-down list.

6.    From the pop-up window that appears, choose the virtual machine(s) that you wish to protect in this job.

a.     The three buttons on the top right of the window can be used to switch between a hierarchical inventory view, a folder view, or a list view of the virtual machines.

b.     The list of virtual machines may be searched for a specific VM name or names using the wildcard character (*) by clicking in the field next to magnifying glass button.

c.     The list of virtual machines can also be filtered using the drop-down list, for example choosing to show only VMs which are currently unprotected.

d.     Individual VMs can be chosen by clicking the checkbox next to their name or it is possible to protect entire clusters, hosts, or folders by clicking the checkbox next to them.

7.    Click Add.

8.    Select a policy from the drop-down list.

9.    Select a storage domain from the drop-down list.

10.  In order to take advantage of the Storage Snapshot integration with Cisco HyperFlex clusters, in the Advanced section, click the Edit link next to “Leverage Storage Snapshots for Data Protection.” Toggle the radio button on, and select Hyperflex from the drop-down list that appears.

11.  Enable App Consistent Backups if necessary, for example if the VM is running transactional software or databases which require the VM’s filesystem to be quiesced as part of the backup. In the Advanced section, click the Edit link next to “App Consistent Backups.” Toggle the radio button on, and optionally choose to fall back to a standard crash consistent snapshot, without quiescing the filesystem, should the quiesce operation fail.

12.  Optionally, modify the remaining job parameters as required. For example, modify the End Date to stop the job from running after a certain date, or change the QoS Policy in order to force the backup job to use the SSDs in the nodes instead of the HDDs.

13.  Click Protect.

The newly configured protection job will perform its initial run immediately, unless it is currently within a blackout period, and the job will repeat itself according to the schedule set forth in the policy.

Recovery

Recovery jobs can be initiated to restore a virtual machine from the backed-up snapshots and return the virtual machine to service. A unique aspect of the Cohesity software is the sequence of the recovery process. When a recovery job is started, the Cohesity system will present an NFS-based datastore from itself, which is mounted to the ESXi host, inside of which are the virtual machine files that have been bloomed from the snapshots. The virtual machine will then be registered in vCenter from this location, and the VM will be powered on. This process returns the recovered VM to service much faster than typical recovery processes will, because the VM will immediately run with its virtual files sourced from the Cohesity NFS datastore. After the VM is powered on, a storage vMotion will relocate the virtual machine files to their original location. The benefit of this recovery workflow is amplified when multiple simultaneous VM recoveries are needed, because the time to return the VMs to service is very low, and the remaining process of relocating the VMs via storage vMotion happens in the background while the VMs are already online. A recovered VM will have no snapshots, even if the VM originally had snapshots at the time of the backup which is being restored.

Recovery jobs can be used to restore multiple virtual machines at one time, however there are two notable limitations to the restoration of multiple VMs. First, in order to restore multiple VMs in a single job, all of the VMs must have originated from the same source. Second, all of the VMs must have been backed up to the same Cohesity storage domain. For example, if some VMs are protected and targeted a storage domain using replication factor 2, meanwhile others were backup up to a storage domain using erasure coding, a single recovery job could only restore the VMs in the storage domain using replication factor 2, and could not recover the VMs in the storage domain using erasure coding. In order to recover both sets of VMs, two recovery jobs would need to be started. Similarly, if VMs originated from multiple sources then multiple jobs must be created to restore them.

Multiple recovery jobs can be created and run simultaneously when the above scenarios apply.

To initiate a recovery operation, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Recovery.

3.    Click the Recover button, from the drop-down list that appears, click VMs.

4.    In the search field, search for the name of the VM or VMs that need to be recovered. Wildcard characters can be used, and additional filters can be applied.

5.    Check the checkbox next to the name(s) of the VMs you wish to recover.

6.    Steps 4 and 5 can be repeated multiple times to select different VMs, for example searching for the name of one VM, selecting it, then clearing the search field, searching for the name of another VM, and then selecting that one as well.

7.    Once all the desired VMs have been selected, click Continue.

8.    The pencil icon next to each VM can be clicked to select the snapshot used as the recovery point. By default, the latest snapshot will be chosen. Choose the desired recovery point in the pop-up window and click Save.

9.    Optionally, toggle the radio button to choose to rename the recovered VMs.

10.  Choose the option to recover the VMs to their original location, or to a new one. Recovery to a new location can only be done to a source already known by the Cohesity cluster, for example, a different vCenter server that is already configured as a source.

11.  Choose the option to keep the networking configuration as it was originally configured, to leave the configuration but leave disconnected, or to leave the network detached.

12.  Choose whether to power the recovered VM on, or to leave it powered off.

13.  Click Finish.

  

The recovery job will immediately start the recovery process and restore the VMs using the settings specified in the job.

Views

A Cohesity View provides network accessible storage distributed across the Cohesity cluster, as either NFS volumes, SMB/CIFS mount paths, or S3 compliant object-based storage. A view targets a specific Cohesity storage domain, taking advantage of the settings in that domain regarding compression, deduplication, encryption, and the efficiency derived from the choice between data replication or erasure coding. In order to mount a view, the client computer must reside in a whitelisted subnet. The views created support the following protocol specific settings and capabilities:

·         NFS version 3.0 is supported, however NLM locking is not supported.

·         NFS mounts and filenames only support ASCII and UTF-8 filenames.

·         SMB versions 3.0 and 2.x are supported.

·         DFS links are not supported.

·         Only NTLMv2 authentication is supported. (Windows 2008 R2 and earlier by default only use LM and NTLM, and therefore must be modified)

·         SMB shares are not automatically discoverable, however they will be found when browsing directly to the Cohesity cluster, for example: \\<Cohesity_cluster_name> or \\<Cohesity_cluster_VIP>

·         In order to define SMB share file and folder level ownership and permissions, the Cohesity cluster must be added to a Microsoft Active Directory domain. Without Active Directory integration, all shares give full control to everyone.

·         Creating a view that contains all 3 protocols results in an S3 view that is read only. In order to create an S3 compliant view that has read/write capabilities, create a view that uses only the S3 protocol.

To create a view, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Views.

3.    Click Create View.

4.    Enter a name for the new View, and optionally enter a description.

5.    Select the desired Storage Domain from the dropdown list.

6.    Select the QoS Policy for this view from the dropdown list. Options include:

a.     Backup Target SSD: The Cluster sends sequential and random I/Os to SSD and the I/Os are not treated as high priority.

b.     TestAndDev High: The Cluster sends sequential and random writes to a distributed journal, which writes to two separate SSDs on different Nodes and acknowledges the I/O. The I/Os with this QoS policy are given higher priority compared to I/Os with other QoS policies except TestAndDev Low.

c.     TestAndDev Low: The same as TestAndDev High, except that the I/Os with this QoS policy are given higher priority compared to I/Os with other QoS policies.

d.     Backup Target High: The Cluster generally sends sequential data to HDD and random writes to SSD.

e.     Backup Target Low: The same as Backup Target High except that the priority for processing workloads with this policy is lower than workloads with Backup Target High.

7.    Click the “Show Advanced Settings” link to expand the list of options available.

8.    Select the protocol(s) to be used for this View by clicking the appropriate radio button.

9.    Modify the additional options for the view being created as necessary. Some options are not available by default, for example setting specific SMB share ownership and default permissions is not available unless the Cohesity cluster has been joined to an Active Directory domain.

10.  Click the Create View button.

Shares

When a new View is created, the name of the View is the default mount path for the clients, and this mount path will establish the top of the file tree. Additional Shares can be created which directly target subfolders within the file tree for ease of navigation. For example, a View can be created for a company division, and then subfolders for each department can be created, each with their own share. End users could navigate to the top of the tree by using the division share, or navigate and map directly to their department share.

To create an additional share within a View, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Views.

3.    Click the ellipses next to the View you wish to modify, then click View Details.

4.    Underneath the Shares & Mount Paths section, click Create Share.

5.    Navigate the file tree to the folder where you wish for the new Share to be.

6.    Enter a name for the new Share then click Create Share.

Global Whitelist

A Global Whitelist is configured to allow all clients which match the IP subnet to access all Views created in the Cohesity cluster. In addition to the Global Whitelist, the whitelist settings can be modified individually in the Advanced Settings of each View.

To modify the Global Whitelist, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Views.

3.    Click Global Whitelist.

4.    Enter an IP subnet and a subnet mask to add to the Global Whitelist and optionally enter a description.

5.    Click Add.

View Protection

Views can also be protected by View Jobs similar to the way virtual machines are protected via Protection Jobs. View protection targets the same Storage Domain configured for the Cohesity View, and will operate according to the same configured Policies as do Protection Jobs.

To configure protection of a Cohesity View, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Platform menu at the top of the screen, click Views.

3.    Click the ellipses next to the View you wish to back up then click Protect View.

4.    Enter a name for the View Job, and optionally enter a description.

5.    Choose a Policy from the drop-down list.

6.    Click Protect.

View Recovery

Unlike a Recovery Job for a VM, which regenerates the VM from the backed-up snapshots, recovery of files from within a View involves creating a Recovery Job, which actually allows you to browse the file tree to locate the file(s) you need to recover. The files can then be downloaded and manually put back into their original locations by the administrative staff.

To recover files from a View snapshot, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Protection menu at the top of the screen, click Recovery.

3.    Click the Recover button, from the drop-down list that appears, click Files or Folders.

4.    Click the radio button for Browse or Specify Path.

5.    Enter the name of the View for which you need to recover files in the search field.

6.    When the protected View appears, click the name of the View.

7.    From the pop-up window that appears, navigate the file tree until you locate the file(s) you need to recover. Click the file, then click Download File.

8.    After all the necessary files have been downloaded locally to your computer, click Close.

9.    Manually copy the downloaded file(s) to their original location the Cohesity View’s file tree.

 

Test/Dev

An additional feature of the Cohesity software is the ability to rapidly clone virtual machines for testing or development purposes. A cloned VM is functionally a restored copy of a snapshot point in time of that VM, and not a clone of the currently running VM. A virtual machine which is cloned using the Cohesity dashboard runs with its virtual machine files and virtual disk files stored in an NFS datastore, which is temporarily mounted by two of the VMware hosts from the Cohesity cluster nodes. Because the VM runs directly from the Cohesity cluster, this use case is appropriate for functional testing, end-user acceptance, and software development or debugging activities, where performance is a secondary consideration. The Clone VMs task gives the administrator the opportunity to rename the cloned VM, clone it to another registered source, and change the network in which the VM is attached. In most cases, manual reconfiguration of the VMs network configuration would be necessary after the clone is created, assuming the VMs use static IP addressing, in order to avoid address conflicts.

To clone a VM for Test/Dev use, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the More menu at the top of the screen, click Test & Dev.

3.    Click the Clone button, from the drop-down list that appears, click VMs.

4.    In the search field, search for the name of the VM or VMs that need to be recovered. Wildcard characters can be used, and additional filters can be applied.

5.    Check the checkbox next to the name(s) of the VMs you wish to recover.

6.    Steps 4 and 5 can be repeated multiple times to select different VMs, for example searching for the name of one VM, selecting it, then clearing the search field, searching for the name of another VM, and then selecting that one as well.

7.    When all the desired VMs have been selected, click Continue.

8.    To rename the cloned VM, toggle the switch for Rename Cloned VMs, then enter a prefix or suffix to add to the name of the VM.

9.    Select the Source from the drop-down list in order to pick the location to clone the VM. The Resource Pool drop-down list will list the hosts or clusters available. The VM Folder will list the available folders to place the VM into. Finally, the View field represents the name of the NFS datastore from the Cohesity cluster which will be mounted to the VMware hosts.

10.  Choose to either leave the networking detached in order to perform manual reconfiguration, or click the radio button for Attach to a new network, and choose the VM port group to attach the cloned VM to.

11.  Choose to leave the VM powered off, or to power it on after the task completes.

12.  Click Finish.

To tear down and delete cloned VMs when they are no longer needed, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the More menu at the top of the screen, click Test & Dev.

3.    From the list of clone jobs presented, click the name of the clone job that created the clone that you wish to remove.

4.    Click the Tear Down Clone button.

5.    Click the Yes, tear down button in the pop-up window that appears.

Monitoring

The Cohesity software offers numerous options for passive and proactive monitoring of the cluster, including job status, performance, hardware status, storage capacity and more.

Dashboard

The Dashboard screen in the Cohesity HTML management webpage provides a useful overview of the status of the overall system health, backup job runs, storage efficiency and performance over the past 24 hours. The dashboard allows the Cohesity administrator to see at a quick glance if any items need attention.

Cohesity Dashboard

Performance

Under the Monitoring menu, the Performance screen can be used to view the storage I/O per second (IOPS), latency and throughput, plus the CPU and memory usage of the nodes in the Cohesity cluster. Views can be modified to see figures for the entire cluster, individual nodes, or individual Storage Domains. The view timeframe can be modified and the view can be zoomed in for greater detail.

Cohesity Performance

 

Alerts

Alerts in the Cohesity cluster can be viewed under the Monitoring menu by clicking Alerts. Alerts can be configured to automatically send a notice to an email recipient as well.

To configure alerts to be sent to an email recipient, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Monitoring menu at the top of the screen, click Alerts.

3.    Click the Edit Alert Settings button.

4.    Enter the email address of the recipient then click Add to List.

Cohesity Alerts

Storage

Under the Monitoring menu, clicking Storage will show a page detailing the storage space consumption in the Cohesity cluster, plus the data reduction efficiency figures due to deduplication and compression. The views in the charts can target the entire cluster or individual Storage Domains, and the timeframe for the charts can be customized.

Cohesity Storage Monitor

Reports

From the Monitoring menu, click Reports to view dynamic reports which can be generated for viewing, exporting, and also as regular emails. There are several report types available, such as backup snapshot summaries, backup job status, cluster health and storage, and many more. Reports can be tailored to show specific date ranges, sources, and statuses, and then configured to be regularly sent via email by clicking the email clock link. Note that not all reports can be configured to send automatically via email.

Cohesity Reports

SMTP

In order to send alerts and/or scheduled reports to recipients via email, the Cohesity cluster’s SMTP settings must be enabled.

To enable SMTP email alerts and reports, complete the following steps:

1.    Log into the Cohesity Dashboard web page.

2.    From the Admin menu at the top of the screen, click Cluster Settings.

3.    Enter a system administrator email address which represents this Cohesity cluster, this will be the “From:” address for outgoing emails.

4.    Toggle the switch to Enable SMTP Server.

5.    Enter the SMTP server information as appropriate for your environment.

6.    Toggle the switch to Test Email on Save.

7.    Click Save.

SNMP

If necessary, SNMP traps can be sent to an SNMP receiver for parsing by a network management system. In the Monitoring > SNMP menu, click Edit to enable and configure SNMP traps, their destination, and the trap user.

Remote Support

Cohesity offers a remote support service named Support Channel, which is enabled by default. Support Channel initiates outgoing sessions to register the Cohesity system with Cohesity’s Support Channel server and technical support team. Cohesity support staff can securely connect and log into the cluster remotely for on-demand technical support and troubleshooting using SSH and secure keys. In some cases, Support Channel connections may require the use of a proxy server to function properly.

Test Plan

Numerous scenarios were developed to rigorously test the integration between the Cohesity systems and Cisco HyperFlex, and also to test the redundancy and durability of the Cohesity system running within the Cisco UCS domain. All of the tests below were executed in Cisco’s labs, using complaint hardware and software as listed previously, and configured according to the instructions in this document. Tests executed included, but were not limited to the following:

Installation

·         Creation and application of Cohesity specific UCS policies and service profiles.

·         Successful installation and initial configuration of Cohesity 6.1.0a software on Cisco UCS managed C240 M5L server hardware.

Core Functional Testing

·         Enable Cohesity Storage Snapshot Provider features.

·         Configure multiple Cisco HyperFlex clusters as Storage Snapshot Provider sources.

·         Configure multiple VMware vCenter systems as sources which manage both single and multiple Cisco HyperFlex clusters.

·         Configure and run Protection Jobs backing up VMs from multiple Cisco HyperFlex clusters.

·         Configure and run a large-scale Protection Job, protecting ~500 VMs which generate random data.

·         Configure and run Restore Jobs restoring VMs across multiple Cisco HyperFlex clusters.

·         Configure Cohesity Views providing NFS, SMB and S3 compliant file services.

·         Configure Test/Dev clones of VMs for temporary use.

Extended Functional Testing

·         Backup and restore VMs to/from multiple Cisco HyperFlex deployment types, including traditional Hybrid clusters, All-Flash clusters, clusters with self-encrypting drives having encryption enabled, extended clusters with compute only nodes, and stretched multi-site clusters.

·         Backup and restoration of VMs running on Cisco HyperFlex version 3.5 and 3.0 clusters.

·         Configure Remote Cluster pairing and replication of snapshots between multiple Cohesity systems.

·         Configure a NetApp FAS array as an External Target and archive backups to the array.

·         Backup VMs using a mixture of jobs with the Storage Snapshot integration both enabled, and disabled.

·         Backup of VMs without existing snapshots and also with existing VMware standard snapshots or existing HyperFlex native snapshots.

·         Restore VMs that had no previously existing snapshots, and also with previously existing VMware standard snapshots and HyperFlex native snapshots.

·         Restore VMs to Cisco HyperFlex clusters that were not the original location of the VMs.

·         Configure Active Directory integration, use AD credentials for logins, and also for setting View ownership and permissions.

·         Configure and test SMTP alerts and reporting.

Failover and Redundancy Testing

All failover and redundancy tests were conducted while at least one active Cohesity Protection Job was running.

·         Fail the active network path for one Cohesity node.

·         Fail the active network path for two Cohesity nodes.

·         Fail all the network uplinks from a single Fabric Interconnect.

·         Fail the active side Fabric Interconnect.

·         Ungraceful shut down the Storage Controller VM (SCVM) of one HyperFlex node.

·         Ungraceful shut down of one HyperFlex node, causing VMs to restart via VMware High Availability.

Bill of Materials

Below is an example Bill of Materials used to order four (4) of the Cisco UCS C240 M5L servers, which are compliant with the requirements to run the Cohesity DataPlatform software, along with the pair of Cisco Fabric Interconnects, and the 10 GbE cables to connect them, as used in the testing and reference design outlined in this document.

Table 29  Cohesity on Cisco UCS Sample Bill of Materials

Primary data can be loosely defined as the mission-critical information required for companies to do business. Secondary data includes backup and recovery, files and objects, test and dev, archive and analytics. Both types of data are growing exponentially, are becoming harder to store, protect and access. Much of it, particularly secondary data, is buried or stored in silos. And, both types of data are becoming more critical for meeting business objectives. To meet compliance and regulatory requirements and to more cost-effectively store, protect and provide business applications with the right data to run them, companies need to modernize their data center operations. Hyperconvergence has been key in replacing slow, siloed data center systems with scale-out software-defined infrastructure on standard hardware with a pay-as-you-grow model.

Cisco HyperFlex and the Cohesity DataPlatform on Cisco UCS are modern, hyperconverged platforms for managing both primary and secondary workloads. Now, these two industry-leading platforms are integrated to deliver an agile web-scale solution, for on premise and cloud, that easily scales with customer’s business needs, consolidates IT operations for all workloads, brings frictionless mobility to data and applications from edge to core to cloud, and put data to work. With the Cisco-Cohesity integrated solution, hyperconvergence meets hyperconvergence. This means customers can easily unify, protect, access and control their data across clouds, data centers or remote and branch offices at a significant cost saving compared to traditional alternatives.

For buyers of servers and storage solutions, who need radically simplified management, predictable pay-as-you-grow pricing, and greater productivity from data, Cisco HyperFlex and Cohesity on Cisco UCS provide unlimited scale, flexibility, and unified management for both primary and secondary data to reduce costs and improve business agility. Unlike antiquated point products that are slow to deploy, costly to purchase, and require expensive over provisioning or disruptive downtime, only Cisco and Cohesity provide a complete, integrated, and flexible hyperconverged infrastructure to help customers modernize and better manage their entire data center. Now, both primary and secondary data and applications can operate at web-scale and empower IT and business with agility to seamlessly support data growth, mobility, and insights – from edge to core to cloud.

For more information on Cisco-Cohesity integrated solution, please see: https://www.cohesity.com/products/cisco.

Brian Everitt, Technical Marketing Engineer, Cisco UCS Data Center Engineering Group, Cisco Systems, Inc.

Brian is an IT industry veteran with over 20 years of experience deploying server, network, and storage infrastructures for companies around the world. During his tenure at Cisco, he has been a lead Advanced Services Solutions Architect for Microsoft solutions, virtualization, and SAP Hana on Cisco UCS. Currently his focus is on Cisco’s portfolio of Software Defined Storage (SDS) and Hyperconverged Infrastructure solutions. Brian has earned multiple certifications from Microsoft, Cisco, and VMware.

Acknowledgements

For their support and contribution to the design, validation, and creation of this Cisco Validated Design, we would like to acknowledge the significant contribution and expertise that resulted in developing this document:

·         Damien Philip, Principal Solutions Architect, Cohesity

·         Sanjeev Desai, Senior Director, Solutions Marketing, Cohesity