AIおよびデータ分析向けReadyソリューション Dell EMCインフラストラクチャ上のCloudera CDP Data Center

Transcription

1 Ready Solutions for AI & Data Analytics Cloudera CDP Data Center on Dell EMC Infrastructure 要旨このリファレンスアーキテクチャでは Dell EMC PowerEdgeサーバーおよびDell EMC PowerSwitchネットワーキングに導入するCloudera Data Platform(CDP)Data Center 7.1.1ソフトウェアの概要 アーキテクチャ および設計情報を示します データ中心型ワークロードおよびソリューション パーツナンバー :H 年 7 月

2 メモ 注意 警告について メモ : メモ は 製品を適切に使用する上で役立つ重要な情報を示します 注意 : 注意 は ハードウェアが破損するかデータが失われる可能性があることを示し 問題の回避方法を提示するものです 警告 : 警告 は 損害 けが または死亡の原因となる可能性があることを示しています 2020 Dell Inc. その関連会社 All rights reserved.( 不許複製 禁無断転載 )Dell EMC および Dell または EMC が提供する製品及びサービスにかかる商標は Dell Inc. またはその関連会社の商標又は登録商標です その他の商標は 各社の商標又は登録商標です

3 目次 第 1 章 : 概要... 5 はじめに... 5 このドキュメントについて... 5 対象読者... 6 フィードバックを歓迎いたします... 6 第 2 章 : データプラットフォームの概要... 7 データプラットフォームとは... 7 アプローチの選択... 7 データプラットフォームアプリケーション... 8 データ管理... 8 ユースケースの例... 9 金融サービス 製造 Apache Hadoopの概要 ClouderaとHortonworks 第 3 章 :Cloudera Data Platform CDP Data Center CDP Data Centerのメリット CDP Private Cloud CDP Private Cloudの概要 CDP Data Centerのコンポーネント 新機能 新たに導入された新機能 CDHからCDP Data Centerへの変更点 HDPからCDP Data Centerへの変更点 第 4 章 :CDP Data Centerへの道のり CDPへの道筋 CDP Data Centerへの移行 CDP Data Centerへのアップグレード 考慮事項 ハードウェアの更新 目次

4 第 5 章 : インフラストラクチャの概要 ソフトウェアインフラストラクチャ クラスターアーキテクチャ 概要レベルのノードアーキテクチャ ロール割り当ての推奨事項 クラスター論理ネットワーク クラスターのサイズ設定と拡張 クラスターのライセンス 高可用性 ハードウェアインフラストラクチャ ネットワークアーキテクチャ Dell EMC PowerEdge ラックサーバーハードウェア構成 第 6 章 : まとめ 本書のまとめ 第 7 章 : 参考資料 Dell EMC ドキュメント Cloudera ドキュメント サービス契約 Dell EMC Customer Solution Centers Dell Technologies InfoHub 詳細情報 目次

5 1 概要 Cloudera Data Platform(CDP)Data Center は Cloudera Data Platform のオンプレミス版です この新製品は Cloudera と Hortonworks の優 れたテクノロジーと 新機能および拡張機能を組み合わせたものです トピック : はじめにこのドキュメントについて対象読者フィードバックを歓迎いたします はじめに データ管理の考慮事項と要件は絶えず進化しています 統一された包括的な方法でデータとデータ中心型ワークロードを企業全体で管理することが 新たな現実問題となっています 以前のユースケースでは データの格納と処理を一括して効率的に行うことに重点が置かれていました それが今 データライフサイクル全体を統合し リアルタイムとバッチの両方でデータを処理する必要性が高まっています テクノロジーインフラストラクチャには コストのかかるネットワーク転送を回避するために コンピューティングとストレージのコロケーションが必要でした 今や ハイパフォーマンス分析のニーズの高まりを受け 分離型ストレージと コンピューティング メモリー SSDの分離への移行が進んでいます ユーザーエクスペリエンスの観点から見ると かつては 製品やサービスを数週間 数か月 さらには四半期のタイムフレームで導入し 稼働することが許容されていました それが今 サービスを数分で起動してユーザーに独自のクラスターを提供し インサイトをすばやく引き出せることが期待されるようになっています かつて プライバシー セキュリティ ガバナンスの観点から見た主な懸念事項は ネットワーク境界と物理的なアクセス制御に関するものでした データライフサイクル全体が管理対象となった今 オペレーターは ワークロードレイヤーとデータレイヤーできめ細かな認証と認可を行う必要に迫られています CDP Data Centerは Cloudera Distribution for Apache Hadoop(CDH) とHortonworks Data Platform(HDP) を統合したものであり お客様に両方の長所をもたらします この新製品は ClouderaとHortonworksの優れたテクノロジーを スタック全体にわたって新機能および拡張機能と組み合わせて データライフサイクル全体を網羅する包括的なデータプラットフォームを形成します この統合ディストリビューションは 拡張性に優れたカスタマイズ可能なプラットフォームであり さまざまな種類のデータ分析ワークロードを安全に実行できます CDP Data Centerは オンプレミスIT 環境向けの包括的なデータ管理および分析プラットフォームとして 次のような機能を備えています データウェアハウスサービスと機械学習サービスデータプライバシーの保護 法令遵守 サイバーセキュリティの脅威防止を複数の環境にわたって実現する 一貫したデータセキュリティ ガバナンス 統制 100% オープンソース ベンダーロックインの回避とイノベーションの加速というお客様の目標をサポートします既存のCDHおよびHDPへの投資をクラウドネイティブアーキテクチャに拡張するための明確な道筋 概要

6 CDP Data Centerには 次のような一般的なワークロードを対象としたデータサービス シェイプ の事前構成済みパッケージが含まれています データを取得 変換 分析するためのデータエンジニアリング データをインタラクティブに閲覧 照会 探索するためのデータマート オンライントランザクション処理 (OLTP) ユースケースのための低レイテンシーでのデータの書き込み 読み取り および永続的アクセスを可能にする運用データベース 独自のサービスを作成する機能 このドキュメントについて このドキュメントでは エンタープライズデータプラットフォームとは何かについての概要を そのメリットと一般的なユースケースとともに示します 具体的には 現行のData Centerエディションとリリース予定のPrivate Cloudエディションの両方を含む Cloudera Data Platformについて説明します また 以下を含むCDPへの道のりについても説明します CDP Data Centerへのアップグレードと移行 CDP Private Cloudの基盤としてのCDP Data Centerの関係インフラストラクチャガイダンスとして Dell EMCでは 高可用性を実現するよう設計された検証済みのリファレンスアーキテクチャを提供しています 以下はその内容です ソフトウェアインフラストラクチャとクラスターアーキテクチャ Dell EMC PowerEdgeサーバーの構成 Dell EMC PowerSwitchネットワーキングのアーキテクチャと構成デル テクノロジーズとClouderaは過去 6 年間にわたって協力し Cloudera 導入環境の設計 計画 構成を合理化するための最適なハードウェアに関するガイダンスをお客様に提供してきました このドキュメントは エンタープライズ実稼働環境の導入と稼働における 両社の集合的経験に基づいています 対象読者 このドキュメントは CDP Data Centerのエンジニアリング 運用 または計画に携わるデータセンターマネージャーとITアーキテクトを対象としています 新規導入以下の製品からのアップグレードまたは移行 Cloudera Distribution for Apache Hadoop(CDH) Hortonworks Data Platform(HDP) CDP Private Cloudの将来の計画に関連する情報も含まれています このドキュメントは Cloudera Data Platformの機能についてある程度の知識があることを前提としています フィードバックを歓迎いたします Dell EMC では ソリューションやソリューションドキュメントへのご意見をお待ちしております Dell EMC Solutions チームに E メールを送信するか ドキュメン トアンケートにコメントを記入してください 著者 : デル テクノロジーズ Data-Centric Workloads エンジニアリングチーム / テクニカルマーケティングチーム メモ : このソリューションに関するその他のドキュメントのリンクについては Dell EMC Solutions InfoHub for Data Analytics を参照してく ださい 概要

7 データプラットフォームの概要 2 この章では データプラットフォームとは何かについてと その使用方法およびメリットについて説明します ユースケースの例からは 特定の業界のデータプ ラットフォームに関するより多くのインサイトを得ることができます トピック : データプラットフォームとはアプローチの選択データプラットフォームアプリケーションユースケースの例 Apache Hadoopの概要 データプラットフォームとは 大半の人はソフトウェアアプリケーション ( 特にモバイルデバイスで使用可能なさまざまな アプリ ) に精通しています アプリケーションは インストールしたその瞬間に価値をもたらす状態になっています ナビゲーション機能を備えたマップアプリケーションのようなものを考えてみてください アプリをインストールし 位置情報サービスをオンにして 住所を入力するだけで 5 分以内に目的地に向かって出発できます 一方 プラットフォームはアプリケーション開発者向けのツールです プラットフォームは インストールされた後 エンドユーザーのためにほとんど何も行いません エンドユーザーが価値を実感できるようになるには まずアプリケーション開発者がプラットフォームを使用して アプリケーションを構成および構築する必要があります 開発者は何十年もの間プラットフォームを使用してきました アプリケーションによっては 開発するのに手間がかかるが 万人にとって有益なコアサービスが必要となる場合があります このような場合は 経験豊富なシステム開発者のグループがプラットフォームを構築し より大規模なアプリケーション開発者コミュニティでそのプラットフォームを利用するのが理にかなっています 開発者の多くは 自力でそれを行うスキルを備えていません 最初に最も大きな成功を収めた例としては リレーショナルデータベース管理システム (RDBMS) が挙げられます これには IBM DB2 Oracle Microsoft SQL Serverなどが含まれます RDBMSカテゴリーは過去数十年間で拡大され より多くのプラットフォームを含むようになりました 数百万人のアプリケーション開発者と数十億人のエンドユーザーが RDBMSプラットフォームを使用して開発されたソフトウェアアプリケーションの恩恵を受けています データプラットフォームが成功する条件は 堅牢であると同時に柔軟性があることです エンタープライズクラスのデータ管理をサポートするために必要な 拡張性に優れた基盤を構築できなかった何百万人ものアプリケーション開発者は データプラットフォームを使用できます 車輪を再発明 しても コストがかかるだけで 優れた輸送手段が生み出されることはめったにありません この教訓にもかかわらず 多くの組織は 独自のデータプラットフォームについて熟考し プロトタイプを作成するために いまだに何か月または何年も費やしています エンタープライズ開発者にとって勇気づけられることは ハイパースケールのインターネット企業の大半が独自のデータプラットフォームを開発し 特定の業界の課題や拡張性の課題に対応していることです これらの企業には Airbnb Facebook LinkedIn Lyft Netflix Twitter Uberが含まれます これらの組織は いくつかの重要な点で従来のエンタープライズ組織と異なります まず 本質的に クラウドネイティブ であるため 開発したプラットフォームがビジネスの要となっています また プラットフォームの構築に必要な経歴を持つ優秀な人材を採用し 保持できます さらに データプラットフォームがその組織のバリュープロポジションにとって不可欠な存在であるため すでに大規模な初期開発投資を絶えず増額しています データプラットフォームの概要

8 アプローチの選択 独自のデータプラットフォームの開発に取り組んでいないほとんどの組織にとって 成功する可能性が最も高いアプローチは ビジネス向けまたはオープンソースのフル機能のデータプラットフォームを採用することです ビジネスバリューを高める独自の創造的な方法でプラットフォーム機能を使用し リッチなアプリケーションを生み出すことに社内の開発労力を集中させます 優れたデータプラットフォームにより 経験豊富な開発者は コアシステム開発者の予想を上回るソリューションを設計することもできます データからインサイトを抽出することの重要性は より多くの組織が理解するようになっています これに応じるかたちで オープンソースおよびビジネス向けソフトウェア業界は データプラットフォームカテゴリーで販売する製品およびサービスの拡大に取り組んでいます これには次の製品が含まれます クラウドデータプラットフォームビッグデータプラットフォームデータ管理プラットフォームデータ分析プラットフォームその他互いに重複する選択肢や競合する選択肢が多数あることを考えると データプラットフォームに投資することで利益がもたらされるかどうかを評価し アプローチを選択するプロセスは 複雑で手間のかかるものになる可能性があります このプロセスに着手する前に 時間とコストをかけて評価するに値する潜在的なメリットを検証しておくと効果的です データプラットフォームアプリケーション パイプラインは データ作業を言い表すための例えとして一般的に使用されます ただし 特定のユースケースに適したツールとプロセスを選択する戦略を策定するにあたっては そのような一般的な説明には限界があります データプラットフォームを採用することで得られる潜在的な価値を判定する最初のステップは できる限り完全なデータパイプラインライブラリーを開発することです データソースによって 多くのパイプラインの重要な要素になるものと 単一の分析タスクに特化したものがあります これらの詳細を追跡することは データプラットフォームの機能を調べる際に 拡張性と信頼性のニーズに影響するため重要です また 次の場合にも役立ちます すべてのパイプラインに必要なステップのタイプと数のパターンを特定する 多くの類似点を持つパターンをグループ化する 1つのプラットフォームでは組織のニーズに対応しきれない場合がありますが ほとんどの状況に多くの共通点があります 図 1. 汎用データパイプライン データプラットフォームの概要

9 図 1. 汎用データパイプライン (8ページ) は 汎用データ分析パイプラインの典型であり さまざまなタイプのデータ作業に必要なエンドツーエンドの機能カテゴリーを示しています このようなハイレベルビューでは データプラットフォームへの投資を評価するには不十分です 収集 などのカテゴリーのタスクの詳細 ( たとえば データソースの数とタイプ ) は データプラットフォームに必要な機能に大きく影響します 強化 カテゴリーの潜在的な多様性と複雑さは ツールとストレージのパフォーマンス評価の際に過小評価されることが少なくありません 図 1. 汎用データパイプライン (8ページ) に示す各パイプライン処理カテゴリーは そのカテゴリーのみに該当する特殊なソフトウェアの市場でもあります プラットフォームと特殊なアプリケーションによっては この図に示す 収集 強化 報告 提供 予測 とは異なる用語が使用される場合があります ただし 概念と機能要件は一般的に同じです データパイプラインのニーズをすべてまたはほぼすべて満たすデータプラットフォームは 生のソースデータからインサイトに至るまでのプロセスをシンプルにします パイプライン内のデータがプラットフォーム間を移動する必要があるときはいつでも 開発フェーズと運用の維持の両方で複雑さが生じる可能性があります データ管理 堅牢なデータプラットフォームを実装することの価値は 幅広いデータソースとデータタイプにあります このデータには 隠された情報や潜在性の情報を データ分析手法を適用するための共通のフレームワークと組み合わせて含めることができます ほぼすべての組織が知っている一般的な分析アプリケーションがある一方で それと同じ数または上回る数の まだ発見も開発もされていない分析アプリケーションがおそらく存在します 多くの組織が認めているとおり 分析からのインサイトに基づいて提案されるアプリケーションのバックログはパンク状態になっています 大規模組織のデータソースの多くは 拡張されて分析パイプラインにマージされていないどころか まだプロファイリングもされていません 分析パイプラインは ソフトウェアアプリケーションまたはレポートに価値を提供します デジタルデータは 構造を持った状態でストレージメディアにコミットされます 例をいくつか挙げてみます ファイルには サイズプロパティとファイルタイプ ( アプリケーション テキスト バイナリ ) があります テキストファイルにはエンコード方式があります 画像には寸法サイズと色深度エンコードがあります オーディオにはビットレートと周波数範囲があります これらの特性は データプラットフォームの要件に影響を与えます ファイルシステムには 多数の小容量ファイルを処理するのに適しているものと 少数の大容量ファイルに適しているものがあります オーディオをはじめとした ストリームベース のデータの場合 データエンジニアは バッファーサイズとファイル作成の特性を選択できます これらの特性は プラットフォームの機能に一致している必要があり 分析にデータを使用する場合の複雑さに影響を与える可能性があります 分析パイプラインの最終段階について豊富な知識がある場合は データ管理の初期段階により多くのインテリジェンスを組み込むことができます レポート作成およびモデリング要件の機能や設定に支障をきたすため データを ダウンサンプリング することはできる限り避けるべきです 分析に不要なときに忠実度の高いデータを保存することは無駄に思えるかもしれませんが 分析要件が変化したときのための保険と考えてください データの信頼性や品質に関する疑問が後で生じたときのために データ生成プロセスに可能な限り一致する形式でデータを保存しておくと 多くの手がかりが得られます ダウンサンプリングをはじめ アーカイブの情報を失う圧縮形式の使用は常に熟慮すべきです IT 担当者が知って驚く データ管理のもう1つの側面は 分析に使用されるデータの複数のコピーを管理するためにストレージが必要になることです 熟練したデータサイエンスの担当者でさえ 同一に見えるデータのコピーを多数消費しています このような状況が必要な理由はいくつかあります レポートおよびモデル開発の両方を 無秩序な変更から分離する必要があります このイニシャルコピーは 通常 ソースの直接コピーであって 変換はほとんどまたはまったく行われません この分離を行うことにより 開発者は正解データに常に戻れるようになります 正解データは 代替の変換スキームと再現性を比較するために使用されます 代替の変換データの管理 よくあるパターンの1つに 時間 地理 市場セグメントなどのさまざまな要因でイベントをグループ化およびカウントすることがあります データプラットフォームの概要

10 効率性 複雑なデータ変換パイプラインは 段階的に開発する必要があります パイプラインの後半になってからタスクの増分セットをテストするためにソースデータに戻るのは非効率的すぎることがあります データサイエンティストは パイプラインを最初から実行することに伴う面倒と時間の投資を減らすために 中間ステップを段階的に実施することを好む場合があります このリストは完全なものではありませんが データプラットフォームのサイズ設定を評価する方法を示しています さらに重要なことは プラットフォーム候補によってもたらされる ストレージの拡張と階層化に利用できる柔軟性を評価できることです データコピー管理の課題に由来するもう1つの要件は 変換ロジックと履歴に関連付けられたメタデータを追跡することです 同一データのコピーを多数作成することは プロジェクトを出荷している最中には合理的に思えるかもしれませんが 6か月後にその理由を確認するのは困難になります こうした中 フィーチャーストア を含むプラットフォームへの関心が高まっています フィーチャーストアのコンセプトは ロジックとメタデータをより適切に追跡し かつ データ管理へのより細分化されたアプローチを促進することです 2つのデータセット間の唯一の違いが顧客ディメンションの管理方法である場合は データセット全体のコピーを2つ保持するのではなく そのフィーチャーのコピーを2つ保持する必要があります これは フィーチャーストアの基本的な考え方を説明する簡単な例です 変換ロジックを再利用して 顧客や製品などの頻繁に使用されるディメンションを 他のすべてのフィーチャーおよびそれらが使用される他のすべての分析データセットから独立して管理すると データ管理が大幅にシンプルになります ユースケースの例 フル機能のデータプラットフォームで対応できるユースケースの潜在的なリストは ほぼ無限です 業種 データソース ビジネス機能 価値の共通部分を調べるだけでも リストが長くなりすぎて文書化できません 次のリストは Dell EMCで頻繁に確認している一般的なユースケースを示しています 顧客の360 度分析小売業界の在庫分析と売上分析製造業界の運用分析 eコマースの詐欺防止ネットワークセキュリティインテリジェンスデータウェアハウスの統合割引価格の最適化金融サービス保険業界の予測分析レコメンデーションエンジンソーシャルメディアの分析とエンゲージメントデータプラットフォームを使用して開発を強化できる 潜在的なユースケースのアクティブリストを作成することをお勧めします このリストに改良を加え 優先順位を付けるためのディスカッションを促します また 優先度が高く 多額の投資を伴う過剰な数のユースケースにあまり早期に取り組まないで済むよう 難易度ランクのスコア (1 5) を作成します 以下のトピックでは 2つのユースケースについて詳しく説明します 金融サービス (10ページ) 製造 (10ページ) データプラットフォームの概要

11 金融サービス 金融サービスには 以下をはじめとした幅広いビジネスモデルが含まれます 消費者向けおよびビジネス向けバンキング個人向けウェルスマネジメント一次または二次資本市場関係管理の重要性は これらすべてのビジネスに共通しており それゆえに分析の重要な焦点となっています 中規模および大規模のほぼすべての金融サービス組織に 1つ以上のデータプラットフォームがあります 他社との競争という強いプレッシャーの下 顧客との関係を見出し 確保し 維持し 育むことは 利益を促進する優先事項となります また 投資リスクを管理し あらゆる規制条件への準拠を保証することも要求されます これには 複数の重複する管轄区域が関与していることがよくあります 個人的な関係が重要であることに変わりはありませんが 金融組織にとっては モバイル オンライン スマートフォン ブランチエージェントなどの複数のチャネルにわたる データ主導のモデリングとレポート作成が不可欠です データ主導の情報を組織で活用することによって信頼を築く組織は ウォレットシェアと生涯価値とともに 顧客からの信頼も高めることができます これを世界規模で達成するには 実績のあるモダンハイブリッドデータプラットフォームを使用してビッグデータと予測分析を活用する必要があります 製造 インダストリー 4.0 は スマートマニュファクチャリングを意味する新語です 先進的なテクノロジーを従来の製造および産業慣行と組み合わせて 全体的な 運用効率を向上させることです インダストリー 4.0 イニシアティブのイノベーションと文書化された成果に後押しされ より多くの製造業者がインダストリアル IoT(IIoT) の概念とテクノロジーを採用するようになっています この採用の動きは 製品開発 サプライチェーン 製造業務を変革しています 最近の多くの事例研究では スマート製品の分析 設計エンジニアリング 現場のオペレーション カスタマーエクスペリエンスを結び付けることで 市場投入 までの期間短縮 製品品質の向上 生産量の拡張を実現する一方で 無駄と運用コストを削減できることが示されています コネクテッド製品は インダ ストリー 4.0 の主要イニシアティブの 1 つです これらの製品が提供する接続性は 人と製品の関係を再形成すると同時に 顧客満足度と収益を高める要 因となっています これらのメリットを実現するには 時として大量の IoT データを取得 処理 分析する機能が必要です データ処理をこのように拡張することにより 製造業 者はほぼリアルタイムの顧客フィードバックにアクセスして 製品品質に関連した問題を特定できます インダストリー 4.0 のもう 1 つの成長分野は インテリジェ ントなサプライチェーンマネジメントです 重要なサプライチェーンで生じた混乱と遅延は セールス部門から運用部門まで組織全体に波及します 多くの製造業者は ほぼリアルタイムのデータ 分析 機械学習を使用して リスクをエンドツーエンドで管理するとともに サプライチェーンが適切に機能し ていることを確認しています 機械学習機能を含む高度な分析をサポートするモダンデータプラットフォームと組み合わせると 製造業におけるこれらの最 新のイノベーションを活用するために必要な投資には 次のものが含まれます 専用センサー GPS RFID プロダクションストリームデータ データプラットフォームの概要

12 Apache Hadoop の概要 Googleのスタートアップインキュベーション段階に 同社の創設者は Web 検索の効率性と検索能力に革命を起こすには 新しいコンピューティングツールを開発する必要があることに気づきました Googleは 以下の問題に対処するために 新しいスケールアウトファイルシステムと新しいスケールアウトコンピューティングプラットフォームの両方を必要としていました 2000 年代初頭にインターネット上に存在していたURLの数ページ間リンク関係の分析の複雑さこれら2つの課題を克服するための1つの方法についての最初の説明は 2003 年から2004 年にホワイトペーパーとして公開されました Hadoop 分散ファイルシステム (HDFS) とHadoop MapReduceコンピューティングプラットフォームの最初のバージョンを開発したYahooの研究者は Hadoopオープンソースイニシアティブの第一歩となったアーキテクチャの基盤があるのは 初期の頃のGoogleホワイトペーパーのおかげであると考えています Cloudera と Hortonworks Clouderaは 2008 年からエンタープライズクラスのデータプラットフォームを提供しています オリジナルの主力製品は Apache Hadoop(CDH) 用の Clouderaディストリビューションでした Hadoopエコシステムの範囲が拡大するに伴い CDHのコアオープンソースコンポーネントも成長を遂げ 充実した プロジェクトのリストを含むようになりました CDHの最新のプロダクションリリース (6.3.x) には 表 1. CDHのコンポーネント (11ページ) にリストされて いるコンポーネントが含まれていました 表 1. CDHのコンポーネント Crunch Flume HBase Hive Hue Impala Kafka Kudu Oozie Phoenix Search Sentry Spark Avro Parquet Clouderaは CDHのこれらのオープンソースコンポーネントのソースコードのコントリビュート 統合 検証 サポートに加えて 完全なデータプラットフォームに必要な 課題を解決する多くのビジネス向けアドオン製品も開発しました Cloudera Manager Cloudera Navigator およびCloudera Data Science Workbenchは 多くのエンタープライズ管理者および開発者の間ですでに採用されているオープンソースコミュニティーからの機能に 追加または代替の価値を提供するツールとサービスを追加します その後 2011 年には Yahoo! の元のHadoopチームからの24 人のエンジニアによって 新しいデータプラットフォーム会社が設立されました Hortonworks は オープンソース オープンスタンダード およびオープンマーケットがイノベーションと成功への最良のアプローチであるという信念に基づいて設立されました Hortonworksは 同様のプラットフォームベンダーであるClouderaおよびMapRと比較して 追加の専用ソフトウェアなしで完全なオープンソースの Hadoopのみを配布しました 同社の主要なソフトウェア製品は Apache Hadoop 上に完全に構築されたHortonworks Data Platform(HDP) でした Hortonworksは 売上を持続するために有料のトレーニングやその他のサポートサービスを利用しました Hortonworksは 同じHadoopプロジェクトの多くをディストリビューションにバンドルしましたが 両者には表 2. HDPとCDHの違い (11ページ) に示すいくつかの違いがあります HDPは 高水準のセキュリティと安定性を維持するエンタープライズクラスのHadoopプラットフォームとして広く採用されました メモ : 表 2. HDP と CDH の違い (11 ページ ) に示す Ambari 以外のすべてのプロジェクトが CDP に含まれています データプラットフォームの概要

13 表 2. HDPとCDHの違い (11ページ) は いくつかの主要な機能に対するHDPとCDHのアプローチの違いを示しています CDPコンポーネントの完全な 詳細 およびCDHまたはHDPからのユーザーにとっての違いについては Cloudera Data Platform (12ページ) を参照してください 表 2. HDPとCDHの違い プロジェクトの機能 HDPプロジェクト CDHプロジェクト 管理 Ambari Cloudera Manager クエリ処理 Hive Impala 認証 Ranger Sentry ガバナンス Atlas Cloudera Navigator ClouderaとHortonworksは2018 年に 両社が合併して1つの会社を設立すると発表しました この合併は2019 年 1 月に完了しました 合併の目標は ハイブリッドおよびマルチクラウド導入環境をサポートするプラットフォームで初のエンタープライズデータクラウドを作成し 100% オープンソースコンポーネント を含めることです 次の章で説明するCloudera Data Platform(CDP)Data Centerは 合併後の会社からリリースされた最初の製品であり ClouderaとHortonworksの優れたテクノロジーをオンプレミス製品に統合したものです データプラットフォームの概要

14 Cloudera Data Platform 3 Cloudera Data Platform(CDP) は 幅広いデータ分析機能を簡単に導入 管理 使用できるよう設計された統合データプラットフォームです CDP は 運用をシンプルにすることで 組織全体で新しいユースケースをオンボーディングするのにかかる時間を短縮します CDP は パブリッククラウド オンプレ ミスデータセンターとしてすでに導入でき オンプレミスプライベートクラウドとしての導入も間もなく可能になります このホワイトペーパーの焦点である CDP Data Center は Cloudera Enterprise Data Hub と呼ばれるようになった Cloudera Distribution for Apache Hadoop(CDH) と Hortonworks Data Platform(HDP) を組み合わせた最初のオンプレミスリリースです メモ : このドキュメントでは Cloudera と Hortonworks の以前のバージョンに言及するときに 通常 それぞれ CDH および HDP と 表記します トピック : CDP Data Center CDP Private Cloud CDP Data Center のコンポーネント 新機能 CDP Data Center CDP Data Centerは 統合データ分析のための包括的なオンプレミスプラットフォームです CDP Data Centerは 取得 処理 分析 実験 導入をカバーし CDHとHDPの優れた機能を統合して 最新かつ最高のオープンソースデータ管理および分析テクノロジーを実現します CDP Data Centerは データセンター内での導入に最適化され プライベートクラウドに対応しています CDP Data CenterのコアレイヤーはCloudera Shared Data Experience(SDX) であり データカタログ スキーマ レプリケーション セキュリティ ガバナンスの統合機能を備えています Cloudera SDX Shared Data Experienceには 次の機能があります スキーマレプリケーションセキュリティガバナンス プラットフォームワークロードが使用および作成する すべてのスキーマおよびメタデータ定義を自動的に取り込んで保存します 企業が機能するために必要なデータコピーとデータポリシーを 完全な一貫性およびセキュリティとともにもたらします フルスタック暗号化やキー管理などのロールベースのアクセス制御を プラットフォーム全体に一貫して適用します パートナー統合のための優れた拡張性とともに エンタープライズグレードの監査 系統 ガバナンス機能をプラットフォーム全体に適用します 図 2. CDP Data Centerの概要レベルのアーキテクチャ (13ページ) は CDP Data Centerアーキテクチャのハイレベルビューを示しています CDP Data Center Runtimeは Apache HDFS Apache Hive 3 Apache HBase Apache Impalaなどのソフトウェアコンポーネントの大規模なセットと 特殊なワークロードに対応したその他多くのコンポーネントで構成されています 完全なリストについては 表 3. CDP Data Centerのソフトウェアコンポーネント (16ページ) を参照してください

15 一般的なワークロードでは クラスターシェイプと呼ばれることもある 事前構成済みサービスパッケージを利用できます 以下のサービスが含まれます データエンジニアリングデータを取得 変換 分析する機能を提供します サービスの例としては HDFS YARN YARN Queue Manager Ranger Atlas Hive Hive on Tez Spark Oozie Hue Data Analytics Studio があります データマート 運用データベース データをインタラクティブに閲覧 照会 探索できます サービスの例としては HDFS Ranger Atlas Hive Impala Hue があります オンライントランザクション処理 (OLTP) ユースケースとリアルタイムインサイトのための低レイテンシーでのデータの書き込み 読み取り および永続的アクセスを可能にします サービスの例としては HDFS Ranger Atlas HBaseがあります 図 2. CDP Data Center の概要レベルのアーキテクチャ Cloudera Manager では サポート対象サービスを任意に組み合わせて導入し カスタムのサービスとクラスターを作成することもできます CDP Private Cloud のリリースに向けて 事前構成されたカスタムパッケージの多くは Analytic Experiences と呼ばれるコンテナ化されたサービスになり ます ストリーミングデータ Cloudera Managerのカスタムサービスオプションを使用すると モニタリングとレプリケーションに加え データ取得とストリームメッセージングに対応した シンプルまたはフルのKafkaクラスターを作成できます これにより Clouderaがストリームプロセッシングおよびストリームメッセージングと呼ぶ機能が提供されます サービスの例としては Kafka Schema Registry Streams Messaging Manager Streams Replication Manager Cruise Control ZooKeeperがあります Clouderaは 最初のCDP Data Centerに続いて 最新のApache NiFiおよびNiFi Registryリリースをサポートする Cloudera Flow Management(CFM) をリリースすることを予定しており その後 Apache Flink Kafka Streams およびSpark Streamingを使用したEdge ManagementとStreaming Analyticsが続きます これらの製品はすべて 最終的にCloudera DataFlow(CDF) プラットフォームと総称されるようになります 機械学習 機械学習 (ML) 機能は CDP Data Center でも利用でき 大規模なコラボレーションデータサイエンスのためのプラット フォームである Cloudera Data Science Workbench(CDSW) をサポートしています CDSW により データサイエンティス トと IT 担当者は独自の分析パイプラインを構築して管理し モデルとインタラクティブビジュアルアプリをすばやく導入できます

16 CDP Data Center のメリット CDP Data Center の主要機能 改善点 メリットは次のとおりです ストリームメッセージング運用効率 ビジネス継続性 拡張性を向上させる 完全で包括的な Kafka ストリーミングエクスペリエンス データエンジニアリング データウェアハウス 機械学習 Apache Sparkのパフォーマンスと相互運用性の向上 データエンジニアリングワークフローの管理 パイプラインの作成 より大規模なデータセットでのSQL 分析の高速化 非構造化データソースから得られる理解の向上 ビジネスインサイトの可視化の容易化 CDP Data Centerで利用可能になったData Science Workbenchによって実験とモデル導入を高度に制御 運用データベース SDX パフォーマンス ポリシー管理 可用性の向上 CDP 全体でセキュリティ コンプライアンス 整合性を強化 インプレース CDH 5.x および HDP 2.x から CDP Data Center へ アップグレードと 移行のサポート CDH または HDP から移行またはアップグレードするユーザーにとっての新機能については CDP Data Center のコンポーネント (16 ページ ) で説明され ています CDP Private Cloud Clouderaがリリースを予定しているCDP Private Cloud 製品は CDPジャーニーの次のステップです CDP Data Centerは CDP Private Cloudの必須コンポーネントであり CDP Private Cloudの基盤を形成して ストレージおよびデータレイククラスターになり SDXレイヤーを含みます そのため CDP Data Centerの新規導入またはCDP Data Centerへのアップグレードを計画するときは CDP Private Cloudについてある程度理解していることが重要です メモ : このドキュメントの公開時点で CDP Private Cloud は計画されていますが まだリリースされていません CDP Private Cloud の概要 Clouderaがリリースを予定しているCDP Private Cloud 製品は お客様の環境でクラウドタイプのエクスペリエンスを実現します CDP Private Cloud は ハイブリッドおよびマルチクラウド環境にわたって強力なセルフサービス分析を提供する データ管理と分析の新しいアプローチです CDP Private Cloudは 分割されたコンピューティングモデルとストレージモデルを活用して 以下のメリットをもたらします マルチテナンシーと分離のシンプル化インフラストラクチャ使用率の向上 Red Hat OpenShift Container Platformによるコンテナ化クラウドネイティブアーキテクチャ

17 図 3. CDP Private Cloudの概要レベルのアーキテクチャ (15ページ) に示すとおり CDP Private Cloudの概要レベルのアーキテクチャには CDP Data Centerとの類似点がいくつかあります CDP Private Cloudは CDP Data Centerで確立されたサービスに基づいて 分析エクスペリエンス と呼ばれる機能をコンテナ化されたサービスとして提供します これには次のものが含まれます データフローおよびストリーミングデータエンジニアリングデータウェアハウス運用データベース機械学習 CDP Private Cloudは Data Centerエディションと同様に セキュリティ メタデータ ガバナンスのすべての機能に対応したCloudera Shared Data Experienceによってサポートされています プラットフォーム全体をカバーする管理コンソールは 複数の導入環境またはクラウドにわたって稼働する統合型の制御プレーンを提供します 図 3. CDP Private Cloud の概要レベルのアーキテクチャ CDP Private Cloud のアーキテクチャ CDP Private Cloud の導入には次の 2 つの側面があります データレイククラスター CDP Data Center 上で稼働します コンピューティングエクスペリエンスクラスター Red Hat OpenShift Container Platform 上で稼働します

18 これら 2 つのクラスターは別個のものであり アーキテクチャおよび導入計画の観点からは互いに独立したトラックです 図 4. CDP Private Cloud のクラス ターとしての CDP Data Center (15 ページ ) は CDP Private Cloud の導入環境全体におけるこれらの主要コンポーネントを示しています 図 4. CDP Private Cloud のクラスターとしての CDP Data Center ご覧のとおり CDP Private Cloud にアップグレードすると CDP Data Center のインスタンスがベースデータレイククラスターになります CDP Data Center( および場合によってはハードウェア ) の更新について計画する際は このリファレンスアーキテクチャガイドに加えて Dell EMC およびインテルイン フラストラクチャガイド :Cloudera Data Platform Private Cloud も参照してください

19 CDP Data Center のコンポーネント Cloudera Runtimeは CDP 内のコアオープンソースソフトウェアディストリビューションであり Clouderaが単一のエンティティとして維持 サポート バージョン管理 パッケージ化しています Cloudera Runtimeには CDP 内のデータ管理ツールのコアディストリビューションを構成する 40を超えるオープンソースプロジェクトが含まれています Cloudera Runtimeには CDPで管理されるクラスターの構成と監視のためのCloudera Managerも含まれています 表 3. CDP Data Centerのソフトウェアコンポーネント (16ページ) は Cloudera Runtime for CDP Data Centerを構成する主要なソフトウェアコンポーネントと 各コンポーネントの簡単な説明を示しています 詳細については Clouderaドキュメント (40ページ) を参照してください 表の後には CDHまたはHDPからCDP Data Centerに移行する場合の変更点と相違点についての説明があります インフラストラクチャの概要 (23ページ) は 各コンポーネントがこのリファレンスアーキテクチャ設計のさまざまなノードのどこに導入されるかを示しています 表 3. CDP Data Centerのソフトウェアコンポーネント コンポーネント バージョン説明 Cloudera Manager Cloudera Managerは 管理者をはじめとした当事者がCDPクラスターとCloudera Runtime サービスを構成 管理 監視するために使用できるWebアプリケーションです また Cloudera Manager APIを使用して 管理タスクをプログラムで実行することもできます Apache Accumulo Accumuloは 堅牢で拡張性に優れたデータストレージと取得機能を提供する ソート済みの分散キーバリューストアです Apache Atlas Atlasは Hadoopにデータガバナンス機能を提供します また 共通メタデータストアとして Hadoopスタックの内外でメタデータを交換するようにも設計されています Apache Arrow Arrowは インメモリーデータ用のクロスランゲージ開発プラットフォームです Apache Avatica Apache CalciteのサブプロジェクトであるAvaticaは データベースドライバーを構築するためのフレームワークです Apache Avro Avroは Apache Hadoop 向けの行指向リモートプロシージャコールおよびデータシリアル化フレームワークです Apache Calcite Calciteは データベースとデータ管理システムを構築するためのフレームワークであり 次の機能を含んでいます SQLパーサ関係代数で式を作成するためのAPI クエリ計画エンジン Apache DataFu DataFuは Hadoopで大規模なデータを処理するためのライブラリーコレクションです Apache Druid Druidは 以下のアイデアを組み合わせることによってリアルタイム分析用の統合システムを作成する分散データストアです データウェアハウス時系列データベース検索システム Cruise Control Cruise Controlは Kafkaクラスターの動的ワークロードリバランシングと自己修復を自動化 します

20 表 3. CDP Data Center のソフトウェアコンポーネント ( 続き ) コンポーネント バージョン説明 Apache Hadoop Apache Hadoopは シンプルなプログラミングモデルを使用して 複数のシステムクラスターにわたる大規模データセットの分散処理を可能にするフレームワークです Apache Hadoop は 単一サーバーから数千サーバーにスケールアウトするよう設計されています Apache HBase HBaseは ネイティブの非リレーショナルデータベースとしてランダムで永続的なデータアクセスを提供します HBaseは エンドユーザーアプリケーションのリアルタイム分析と表形式データを必要とするシナリオに最適です Apache HDFS Hadoop Distributed File Systemは Javaベースのファイルシステムであり 大量のデータに対して拡張性と信頼性の高いデータストレージを提供します Apache Hive Hiveは 巨大な異種データセットを要約 照会 分析するためのデータウェアハウスシステムです Hue Hueは データウェアハウスを操作するために使用される Webベースのインタラクティブなクエリエディターです Apache Impala Impalaは Apache Hadoopファイル形式で保存されたデータに対してハイパフォーマンスで低レイテンシーのSQLクエリを提供します Apache Kafka Kafkaは ハイパフォーマンスで高可用性 かつ冗長なストリーミングメッセージプラットフォームです Kafkaは パブリッシュ / サブスクライブメッセージングシステムのように機能しますが 次の特長があります 優れたスループット統合型のパーティション分割レプリケーションフォールトトレランス Apache Knox Knoxは 1つ以上のHadoopクラスターのREST APIおよびユーザーインターフェイスを安全に操作するためのアプリケーションゲートウェイです Apache Kudu Kuduは 高速な挿入と更新 および効率的な列スキャンを組み合わせて 単一のストレージレイヤー全体で複数のリアルタイム分析ワークロードを実行できるようにします Kuduは 高速データの高速分析を実現します Apache Livy Livyは RESTインターフェイスを介してSparkクラスターを簡単に操作できるようにするサービスです Apache Oozie Oozieは Apache Hadoopジョブを管理するためのワークフローおよび調整サービスです Apache ORC Optimized Row Columnar(ORC) は Hadoop 用に設計された 自己記述型で型認識の列指向ファイルフォーマットです Apache Ozone( ベータ ) Ozoneは Big Dataワークロード用に最適化された 拡張性と冗長性に優れる分散オブジェクトストアです ベータ版は本番稼働用ではありません Apache Parquet Parquetは 以下の要因にかかわらず Hadoopエコシステムのあらゆるプロジェクトで使用できる列指向ストレージフォーマットです データ処理フレームワークの選択データモデル プログラミング言語

21 表 3. CDP Data Center のソフトウェアコンポーネント ( 続き ) コンポーネント バージョン説明 Apache Phoenix Phoenixは プログラミング向けANSI SQLインターフェイスを提供するApache HBaseのアドオンです Apache Ranger Rangerは CDPサービスへのアクセスを制御できるCDPセキュリティコンポーネントです アクセスの監査とレポート作成の機能も提供します Schema Registry Schema Registryは 基盤となるストレージメカニズムとしてKafkaを使用する スキーマの分散ストレージレイヤーです Cloudera Search Cloudera Searchは Hadoop HBase またはクラウドストレージに保存または取り込まれたデータを対象に Apache Solrを使用した全文検索と自然言語アクセスの統合機能を提供します Apache Solr Solrは Hadoop HBase またはクラウドストレージに保存または取り込まれたデータへの自然言語アクセスを提供します Apache Spark Sparkは 大規模なデータ処理と分析用に設計された分散型インメモリーデータ処理エンジンです Apache Sqoop Sqoopは リレーショナルデータベースとHDFSまたはクラウドオブジェクトストア間でデータを一括転送するCLIベースツールです Streams Messaging Manager Streams Messaging Managerは 企業のApache Kafka 環境にエンドツーエンドの可視性をもたらす運用監視および管理ツールです Streams Replication Manager Streams Replication Managerは フォールトトレラントで拡張性に優れ かつ堅牢なクロスクラスター Kafkaトピックレプリケーションを可能にする エンタープライズグレードのレプリケーションソリューションです Apache Tez Tezは ハイパフォーマンスのバッチアプリケーションとインタラクティブなデータ処理アプリケーションを構築するための拡張可能なフレームワークです アプリケーションはApache Hadoopで YARNによって調整されます Apache YARN YARNは ネットワーク内の複数のマシンで実行される分散アプリケーションを管理する処理レイヤーです Apache Zeppelin Zeppelinは HadoopとSparkに次の機能をもたらす多目的のWebベースノートブックです データ取得データ調査可視化共有コラボレーション Apache ZooKeeper ZooKeeperは 以下の目的で使用される一元管理サービスです 構成情報の維持名前付け分散型同期グループサービスの提供

22 新機能 どの機能とコンポーネントが以前のリリースと比べて新しいかを把握し どの機能が以前のリリースになかったまったく新しい機能であるかを確認して 以下について理解しておくことをお勧めします CDPアーキテクチャ CDP Data Center 7.1.1に含まれる広範なコンポーネント多くのユーザーがレガシーのClouderaおよびHortonworksリリースからCDP Data Centerに移行していることこのトピックでは リリースの内容について説明しますが アップグレードや移行の道筋をはじめとしたCDP Data Centerへの道のりの詳細は CDP Data Centerへの道のり (20ページ) に記載されています 新たに導入された新機能 今回初めて導入された新機能がいくつかあります これらの機能は CDH と HDP の以前のリリースに含まれていた機能に追加されたもので その意味で CDP Data Center を導入するすべてのユーザーにとって新しい機能です 新機能には以下が含まれます Atlas 2.0 セキュリティ機能の強化ストリーミングサービス Ozone オブジェクトストレージ 高度なデータ検出 メタデータカタログと検索 データ系譜とCoC メタデータ監査 セキュリティ強化のサポートが含まれます また Sparkのサポートも含まれます Ranger KMS-Key Trustee 統合による暗号化が含まれ Navigator Encrypt(Navencrypt) によって静止データを保護します Kafkaと関連コンポーネントの追加に伴って導入されました Kafkaクラスターのクラスター管理とレプリケーション スキーマレジストリーサービスによるストレージとスキーマ Cruise Controlを使用したクラスターの再バランシングが含まれます また HDFS Amazon S3 Kafka Streamsへの接続を可能にするKafka Connectにも対応しています ベータ版として提供されており HDFSのイレイジャーコーディング機能を備えています Ozoneは オブジェクトストアとHDFS を橋渡しし 数十億個のオブジェクトをサポートする次世代のファイルシステムです CDH から CDP Data Center への変更点 CDH の以前のユーザーにとって新しい機能は次のとおりです Rangerセキュリティ Hive 3データウェアハウスソフトウェア Hive on Tez きめ細かいアクセス制御 動的行フィルタリング 動的列マスキング 属性ベースのアクセス制御を使用して ポリシーと認可を設定するための完全な動的機能を提供します Impalaをディストリビューションの一部に含めると ImpalaとRangerの統合が可能になり Impala Hive Kuduに任意のポリシーを伝播できるようになります 不可分性 整合性 分離性 耐久性 (ACID) のサポートにより ETLパフォーマンスが向上し ANSI SQL2016が包括的にカバーされます HiveをTezと統合します Tezは ハイパフォーマンスのバッチアプリケーションとインタラクティブなデータ処理アプリケーションを構築するための拡張可能なフレームワークであり ペタバイト規模でETLパフォーマンスを向上させます

23 HDP から CDP Data Center への変更点 HDP の以前のユーザーにとって新しい機能は次のとおりです 仮想プライベートクラスター Hue Kudu Impala 仮想プライベートクラスターは アプリケーションの導入をシンプルにし 複数の異なるクラスターで実行されているワークロードが安全かつ柔軟にデータを共有できるようにします Hueは データベースやデータウェアハウスを操作するためのWebベースのインタラクティブクエリエディターです オートコンプリート 可視化 HiveおよびImpalaとの接続機能を備えた統合 SQLエディターによって SQLクエリをシームレスに実行します Kuduは 高速データを高速分析するための列指向ストレージマネージャーです 可変文字フィールド (varchar) とデータ型列 Ranger Authz 統合 更新可能データの高速変更をサポートして パフォーマンスを向上させます Impalaは 超並列処理 (MPP) クエリ用のSQLクエリエンジンです データマートの移行と対話型 SQLのほか TableauをはじめとしたBIツールを使用したアクセスレポートやダッシュボードなどのビジネスインテリジェンス (BI) スタイルのクエリに最適です Cloudera Manager Cloudera Manager は 複数のクラスターを管理するために使用する Web アプリケーションです HDP の Apache Ambari から の変更点であり 自動ワイヤ暗号化セットアップ 管理者向けのきめ細かなロールベースアクセス制御 (RBAC) 合理化さ れたメンテナンスワークフローが含まれています

24 CDP Data Center への道のり 4 この章では CDP Data Centerへのアップグレードの道筋について説明します また データの移行やプラットフォームのアップグレードなど CDHおよびHDP からCDP Data Centerに移行する方法の概要を示します メモ : このドキュメントでは 考えられるアップグレードの道筋と一部の考慮事項について説明しますが 必要な手順をすべて説明することが目的ではありません トピック : CDPへの道筋 CDP Data Centerへの移行 CDP Data Centerへのアップグレード考慮事項 CDP への道筋 CDP Data Center への道筋は 新規インストール つまり グリーンフィールド インストール以外にもいくつかあります 既存のインストールを使用する場合 は 次の 2 つのアプローチがあります 移行 このアプローチでは 図 5. 移行とアップグレードの比較 (20 ページ ) の左に示すとおり 次の操作を行います 新しい CDP Data Center クラスターをオンプレミスと新規ハードウェアインフラストラクチャに導入します 既存のクラスターからデータとメタデータをコピーします 既存のワークロードを移行します インプレースアップグレードでサポートされるアップグレードの道筋 このアプローチでは 図 5. 移行とアップグレードの比較 (20 ページ ) の右に示すとおり 次の操作を行います レガシークラスターから CDP Data Center にアップグレードするために必要な準備を行います 同じハードウェアインフラストラクチャでインプレースアップグレードを実行します への道のり

25 図 5. 移行とアップグレードの比較 両方のアプローチの詳細については それぞれ以下を参照してください CDP Data Center への移行 (20 ページ ) CDP Data Center へのアップグレード (21 ページ ) CDP Data Center への移行 移行が最善のアプローチまたは最も適切なアプローチであるシナリオは複数あります 以下にその例を示します 新しいクラスターに容量がある場合 容量の増大やパフォーマンスの向上などのためにハードウェアを更新している場合 既存のワークロードを停止したくない場合 ワークロードを一度に1つずつ移動できる場合 ダウンタイムを一切発生させたくない場合 直接アップグレードがサポートされていないCDHおよびHDPの既存のインスタンスがある場合 以下をはじめとしたツールを使用できます Workload XM Replication Manager ワークロードを分析後に移行またはシフトでき ワークロードを 1 つずつ移動できます データとメタデータのレプリケーションとコピーが可能です 移行プロセスは次のとおりです 新しいクラスターをセットアップします 移行候補のワークロードを特定します データとメタデータをコピーします ワークロードを移行してテストします 新しいクラスターとワークロードを本番環境にプロモートします レガシークラスターを廃止します ハードウェアの互換性に応じて 新しいCDP Data Centerクラスターにノードを追加して容量を増大します このプロセスでは 次の両方を行うことによって クラスターのローリング移行を実行できます 新しいハードウェアを導入する データとワークロードを新しいクラスターに徐々に移行することにより 既存のハードウェアを転用する への道のり

26 移行プロセスの概要は図 6. CDP Data Center への移行 (21 ページ ) に示すとおりです 図 6. CDP Data Center への移行 CDP Data Center へのアップグレード 次のような場合は 移行よりもインプレースアップグレードの方が適切であるか 移行を実行できないことがあります 使用可能な追加のハードウェア容量がない 優先度の低い環境でアップグレードをテストできるクラスターが複数ある 単一テナントクラスターなど ダウンタイムに対するワークロードの耐性が高い 複数のタイプのジョブがクラスターで実行されていない アップグレードツールには以下が含まれます Cloudera Manager CDH ユーザーの場合 Cloudera Manager7.1.1 によって以下のプロセスを円滑化できます 以前のバージョンの Cloudera Manager からのアップグレード すべてのコンポーネントを使用した 以前のランタイムから現在のランタイムへのアップグレード Apache Ambari HDP ユーザーのアップグレードを管理します 潜在的な互換性の問題を回避するため アップグレードは通常 プロフェッショナルサービス契約を利用して行われます 現在のリリースであるCDP Data Center 7.1.1では 以下のリリースからのアップグレードがサポートされています CDP Data Center 7.0 CDH HDP 移行プロセスの概要は図 7. CDP Data Centerへのアップグレード (22ページ) に示すとおりです への道のり

27 図 7. CDP Data Center へのアップグレード 考慮事項 レガシー環境は複雑で多様な場合があります アップグレードまたは移行のリスクを低減するために 計画プロセス中に考慮する必要のある要因がいくつかあります アップグレードは複雑で 多くの前提条件があります 前提条件の例は次のとおりです 個々のコンポーネントのバージョンをアップグレードするプラットフォーム全体をアップグレードする前に さまざまなコンポーネントへの変換を行うまた CDHからアップグレードするかHDPからアップグレードするかによっても違いがあります HDPプロセスには Cloudera Managerに変換する前に Apache Ambariをアップグレードして使用するなどの中間ステップが必要です メモ : 計画を立てることは非常に重要です サポートが必要な場合は Cloudera のジャーニーワークショップに参加して計画に役立ててください アップグレードまたは移行のリスクを低減するには プロセスを開始する前に データのレプリケーションと保護について検討する必要があります 計画をまだ策定していない場合は 次のマルチクラスターレプリケーションシナリオを検討してください レガシークラスターをアップグレードする場合新しいクラスターをゼロから始める場合 ハードウェアの更新 アップグレードまたは移行の計画期間は ハードウェアのアップグレードが必要かどうかや ハードウェアをアップグレードすることで恩恵を受けられるかどうかを検討するのに理想的なタイミングです 容量とパフォーマンスの両方の観点から計画を立てるには 以下の点を検討します CDP Data Centerのハードウェアインフラストラクチャ要件 ハードウェアの概要 (23ページ) を参照してください CDP Private Cloudのハードウェア要件 ( 将来的にそのエディションにアップグレードする予定がある場合 ) メモ :CDP Private Cloud のハードウェア要件については Dell Technologies InfoHub の Dell EMC およびインテルインフラストラクチャガイド :Cloudera Data Platform Private Cloud を参照してください への道のり

28 5 インフラストラクチャの概要 この章では Cloudera Data Platform Data Center の導入に固有のインフラストラクチャ構成ガイダンスを示します トピック : ソフトウェアインフラストラクチャ クラスターアーキテクチャ ハードウェアインフラストラクチャ ソフトウェアインフラストラクチャ 表 4. ソフトウェアコンポーネント (23ページ) は Cloudera CDP Data Center on Dell EMC Infrastructureでサポートされるソフトウェアコンポーネ ントとバージョンを示しています 表 4. ソフトウェアコンポーネント カテゴリー コンポーネント バージョン オペレーティングシステム RHEL ファイルシステム XFS 該当せず Java 仮想マシン Open JDK 1.8u Oracle Java 1.8 Cloudera Data Platform CDP Data Center Cloudera Manager ファームウェア idrac ネットワークインターフェイスカード Dell EMC PERC H740P データベース MySQL 5.7 MariaDB 10.2 PostgreSQL 10 Oracle 12 インフラストラクチャの概要

29 クラスターアーキテクチャ このトピックでは以下の内容を取り上げます 概要レベルのノードアーキテクチャ (24ページ) ロール割り当ての推奨事項 (25ページ) クラスター論理ネットワーク (25ページ) クラスターのサイズ設定と拡張 (26ページ) クラスターのライセンス (28ページ) 高可用性 (28ページ) 概要レベルのノードアーキテクチャ 図 8. ノードアーキテクチャ (24 ページ ) は Cloudera Data Platform Data Center の概要レベルアーキテクチャを示しています 図 8. ノードアーキテクチャ インフラストラクチャの概要

30 クラスター環境は 複数の物理サーバーノードを実行する複数のソフトウェアサービスで構成されます この実装では サーバーノードをいくつかのロールに分割し 各ノードはクラスターでのロールに合わせて構成が最適化されています 物理サーバー構成は 次の 2 つのクラスに大きく分けられます ワーカーノード マスターノード ワーカーノードは Hadoop 処理の大部分を処理します マスターノードは クラスター操作に必要なサービスをサポートします ハイパフォーマンスなネットワークファブリックが クラスターノードを互いに接続し 管理機能とコアデータネットワークを分離します サポートされる最小構成は8 個のクラスターノードで これには マスターノード3 個 ユーティリティーノード1 個 エッジノード1 個 ワーカーノード3 個が含まれます 5 個のワーカーノードを持つ10ノードクラスターから始めるのが一般的な方法です 各ノードには 表 5. クラスターノードのロール (24ページ) に示すロールがあります メモ : これらのノードのロールはすべて必要です 表 5. クラスターノードのロール ノードのロールマスターノードユーティリティーノードエッジノードワーカーノード ハードウェアの構成インフラストラクチャインフラストラクチャインフラストラクチャワーカー 表 6. ノードの定義 ノードマスターノードワーカーノードユーティリティーノードエッジノード 定義クラスターストレージとコンピューティングサービスの管理に必要なすべてのデーモンを実行しますローカルハードドライブのデータブロックの格納と そのデータに対する処理タスクの実行に必要なすべてのサービスを実行します Cloudera ManagerとCloudera Management Serviceを実行しますゲートウェイ構成を含む クライアント向けの設定構成とサービスをすべて格納します インフラストラクチャの概要

31 ロール割り当ての推奨事項 表 7. CDP Data Center のノードとロール (25 ページ ) は 高可用性の中規模導入環境向けに推奨されるホストのロール割り当てについて説明したも のです 表 7. CDP Data Center のノードとロール ノード サービス マスターノード1 NameNode JournalNode FailoverController YARN ResourceManager ZooKeeper JobHistory Server SPARK History Server Kuduマスターマスターノード2 NameNode JournalNode FailoverController YARN ResourceManager ZooKeeper Kuduマスター マスターノード 3 JournalNode ZooKeeper Kudu マスター ( 高可用性を実現するには 奇数個のマスターが 必要 ) ユーティリティーノード 1 Cloudera Manager Cloudera Manager Management Service Hive Metastore Impala Catalog Server Impala StateStore Oozie ZooKeeper( 専用ディスクが必 要 ) JournalNode( 専用ディスクが必要 ) Apache Atlas Apache Ranger エッジノード ワーカーノード Hue HiveServer2 Gateway 構成 DataNode Node Manager Impalad Kudu tablet サーバー ロールの割り当てに関するこれらの推奨事項は 構成検討のための出発点となる点を意図しています クラスターのサイズと利用するサービスに応じて ロールの割り当てが異なる場合があります 詳細については CDP Data Center ドキュメントの ランタイムクラスターホストとロール割り当て を参照し てください クラスター論理ネットワーク 3 つの異なるネットワークがクラスターで使用されます 表 8. Apache Hadoop の Cloudera ディストリビューションのネットワークの定義 (25 ページ ) は ネットワークとその目的を説明したものです 表 8. Apache Hadoop の Cloudera ディストリビューションのネットワークの定義 ネットワーク説明使用可能なサービス クラスターデータネットワーク データネットワークは クラスター内の膨大なトラフィックを伝送します このネットワークは各ポッド内に集約されており ポッドはクラスタースイッチに集約されています Cloudera Enterpriseサービスはこのネットワークで使用可能です メモ :Cloudera Enterpriseサービスはマルチホーミングをサポートしておらず クラスターデータネットワークでのみ利用可能です インフラストラクチャの概要

32 表 8. Apache HadoopのClouderaディストリビューションのネットワークの定義 ( 続き ) ネットワーク 説明 使用可能なサービス idrac/bmcネットワーク BMCネットワークは スイッチのBMCまたは idracポートおよび帯域外管理ポートを接続し ハードウェアのプロビジョニングと管理に使用されます このネットワークは 各ラックの管理スイッチに集約されます このネットワークは サーバーのBMC/iDRAC 機能へのアクセスを提供し クラスタースイッチの管理ポートへのアクセスにも使用されます エッジネットワーク エッジネットワークは エッジノードから既存のネッ トワークへの接続を 直接提供するか クラス タースパインスイッチを介して提供します このネットワークでは エッジノードへの SSH アク セスを利用できます 他のアプリケーションサービ スが構成され 使用可能な場合もあります クラスターと既存のネットワークインフラストラクチャの間の接続は 特定のインストールに適合させることができます 一般的なシナリオは次のとおりです クラスターデータネットワークは既存のネットワークから分離されており クラスターへのアクセスにエッジネットワークのみが使用される場合 クラスターデータネットワークが既存のネットワークに公開されている場合 このシナリオでは エッジネットワークは使用されないか アプリケーションアクセスまたはデータ取得処理プロセスに使用されます いずれの場合も 企業ルーターはクラスターノードへのアクセスを制御するために使用されます 図 9. クラスター論理ネットワーク (26 ページ ) は クラスター論理ネットワークの詳細を示しています 図 9. クラスター論理ネットワーク インフラストラクチャの概要

33 クラスターのサイズ設定と拡張 このアーキテクチャは Hadoop 環境の拡大に合わせて3 段階のサイズ設定で構成されます 段階は次のとおりです ( 最小から最大 ) ラックポッドクラスターどの段階にも このアーキテクチャガイドに記載されている特性とサイズ設定に関する考慮事項があります Hadoop 環境の設計目的は 既存のコンポーネントを置き換えずに必要に応じて容量を追加することによって環境を拡張できるようにすることです ラックのサイズ設定 ラックは 最小サイズのHadoop 環境の名称です ラックは ワーカーノードのグループをサポートするための電源 ネットワークケーブル データおよび管理スイッチで構成されます ラックは物理的なユニットであり その容量は 空き領域 電力 冷却 床の耐荷重量などの物理的な制約によって定義されます 1 台のラックではデータセンター内の独自の電源を使用し その他のラックから独立させてフォルトゾーンとして扱う必要があります マルチラックポッドまたはクラスターでラックレベルの障害が発生した場合 クラスターは容量を減らして機能し続けます このアーキテクチャでは 通常のラックサイズは12ノードですが これより多くすることも少なくすることも可能です 通常 1ラックには Dell EMC PowerEdge R640やDell EMC PowerEdge R740xdなどのスケールアウトサーバーを使用する約 12ノードが含まれます ラックのノード密度は クラスター全体の拡張とサイズ設定には影響を与えませんが クラスター内のフォルトゾーンには影響を与えます ポッドのサイズ設定 ポッドは クラスターの最初のレベルのネットワークスイッチに接続されているノードのセットであり 1 台以上のラックで構成されます ポッドは 最初のうちは少ないノード数から始め 徐々に最大数まで拡張することができます ポッドは ラックレベルより上の 第 2レベルのフォルトゾーンです 複数のポッドクラスターでポッドレベルの障害が発生した場合 クラスターは容量を減らして機能し続けます ポッドは 商用規模の設置に最小限必要なHadoopサーバーノードとネットワークスイッチをサポートします このアーキテクチャでは 1 台のポッドで最大 36ノード ( 公称はラック3 台 ) をサポートします このサイズは クラスター全体のポッド間で2.25:1の帯域幅のオーバーサブスクリプションになります ポッドのサイズは このベースラインの推奨値とは異なる場合があります ポッドのサイズを変更すると ポッドレベルの帯域幅のオーバーサブスクリプション フォルトゾーンのサイズ 最大のクラスターサイズに影響します クラスターのサイズ設定 クラスターとは単一のHadoop 環境であり クラスター全体の集約レイヤーを構成するネットワークスイッチのペアに接続しています クラスターのサイズは 単一のラックにある単一のポッドから 複数のラックにある多数のポッドまでさまざまです 単一ポッドクラスターは特殊なケースであり 集約レイヤーなしで機能できます これは 通常 ポッドを追加する前の小規模なクラスターに該当します このアーキテクチャでは クラスター内のノードの最大数が レイヤー 2またはレイヤー 3スイッチングの選択 および使用されるスイッチモデルによって異なります 制限については クラスターノード数 (27ページ) を参照してください クラスターノード数 サポートされる最小構成は8ノードです マスターノードx 3 ユーティリティーノードx 1 エッジノードx 1 ワーカーノード x 3 インフラストラクチャの概要

34 クラスターごとに少なくとも1つのエッジノードが必要ですが より大規模なクラスターや 取得量または取得率が高いクラスターでは 追加のエッジノードが必要になる場合があります Clouderaは 20 個のワーカーノードごとに1 個のエッジノードのベースラインを設定することを推奨しています 表 9. 推奨されるクラスターサイズ設定 (27ページ) は ポッドあたりのノード数とクラスターあたりのポッド数の推奨値を示しています また 帯域幅のオーバーサブスクリプション率が異なる場合のクラスターサイズ設定の代替案も示しています メモ : このガイドのネットワーク設計では 2.25:1 のオーバーサブスクリプション率を使用しています 表 9. 推奨されるクラスターサイズ設定 ラックあたりのノード数 ポッドあたりのノード数 クラスターあたりのポッド数クラスターあたりのノード数帯域幅のオーバーサブスクリプション率 : : : :1 クラスターストレージのサイズ設定 クラスターの合計ストレージ容量は 選択したサーバープラットフォームとディスクドライブによって決まり ワーカーノード数に応じて拡張されます クラスターで使用可能なストレージの量は 使用されるデータ耐久性のタイプと使用されるデータ圧縮のタイプにも依存します 有効ストレージ容量は 次のように計算されます この計算は簡単ですが ストレージ効率と圧縮比の見積もりに左右されます Hadoop Distributed File System(HDFS) ストレージシステムは データの耐久性を実現するため レプリケーションとイレイジャーコーディングという ストレージ効率の異なる2つのオプションをサポートしています HDFSは レプリケーションの使用時に 複数のノードにわたって複数のデータコピーを作成することによってデータロスを防ぎます レプリカの数 ( レプリケーション係数 ) は設定可能であり ファイルごとに変更できます デフォルトのレプリケーション係数は ストレージ容量の見積もりに一般的に使用される値 3です HDFSレプリケーションは レプリケーション係数の分だけストレージ効率を低下させます イレイジャーコーディングを使用すると データはブロックに分割されて パリティでエンコードされ 複数のノードに分散されます エンコーディングの詳細は イレイジャーコーディングポリシーで指定されます イレイジャーコーディングポリシーにより データの耐久性とストレージ効率の間のトレードオフが可能になります たとえば リードソロモン6-3ポリシーの耐久性は3 ストレージ効率は67% であるのに対し リードソロモン3-2ポリシーの耐久性は2 ストレージ効率は60% です 圧縮を使用して 必要なストレージを削減することもできます 圧縮はオプションであり 個々のファイルに適用されます HDFSは複数のデータ圧縮コーデックをサポートしており 圧縮ファイルごとに異なるコーデックを使用できます 特定のファイルで達成できる圧縮比は 使用するデータセットとコーデックの両方によって左右され 見積もるのが困難です 最善のアプローチは次のとおりです 実際のデータセットでいくつかの異なるコードをテストし 何が最も効果的かを判断します 圧縮されるデータの量を見積もります マスターノードのハードウェア構成は ペタバイトストレージ範囲のクラスターを変更なしでサポートします インフラストラクチャの概要

35 クラスターのライセンス クラスターのCDP Data Centerライセンスは 以下に基づいています クラスター内のノードの数利用可能な計算容量 ( 測定単位はCloudera 計算ユニット (CCU)) 利用可能なストレージ容量 ( 測定単位はTB) この計算では 16 CCUと48 TBを含む ノードあたりの基本価格を使用します ストレージとCCUはクラスター全体で集約され クラスターの基本割り当てを上回るCCUとストレージには変動価格が適用されます このドキュメントの発行日現在 1 CCUは 物理 CPUコア1 個と8 GBのRAMに相当します このアーキテクチャガイドで推奨される構成では 設計の一部としてライセンスコストが考慮されています 詳細については Clouderaドキュメントの プラットフォームの価格設定 を参照してください 高可用性 このアーキテクチャは ハードウェアの冗長性とソフトウェアサポートの組み合わせによって複数のレベルで高可用性 (HA) を実装します Hadoop の冗長性 ネットワークの冗 長性 HDFS 高可用性 NameNode リソースマネー ジャーの高可用性 データベースサー バーの高可用性 HDFSは レプリケーションとイレイジャーコーディングを通じてデータ耐久性のための冗長ストレージを実装し ノードとラックの局所性を認識します 実稼働ネットワークは 各ポッドのスイッチのペアと集約レベルのスイッチペアへのボンディング接続をオプションで使用できます この構成によって帯域幅の容量が増加し ネットワークポート ネットワークケーブル またはスイッチの障害が発生した場合は容量を減少させる運用が可能になります コアファブリックとして25 GbEを使用する場合 ボンディングネットワークは通常使用されません 大規模クラスターの場合は スパインスイッチレベルでネットワーク冗長性をもたらすレイヤー 3の集約を使用することをお勧めします このアーキテクチャは 複数の物理ノードにわたって重要なNameNodeデータをレプリケートするクォーラムメカニズムによって HDFSディレクトリーの高可用性を実現します このアーキテクチャは Hadoop YARNリソースマネージャーの高可用性をサポートします リソースマネージャーのHAがなければ Hadoopリソースマネージャーの障害によって実行中のジョブが失敗します リソースマネージャーに障害が発生した場合 リソースマネージャー HAが有効になっていると ジョブは実行を継続できます メモ : 実稼働クラスターには リソースマネージャー HA を使用することをお勧めします このアーキテクチャは 実稼働データベースの高可用性をサポートします Cloudera Managerの運用データベースとメタデータデータベースの両方に使用されるデータベースサーバーは データをRAID 10パーティションに保存し ドライブで障害が発生した場合に冗長性を提供します メモ :Dell EMC のデフォルトのインストールでは単一の PostgreSQL インスタンスが使用されるため 単一障害点があります データベースサーバーの高可用性は 以下を使用して実装できます クラスター内の他のノード上にある 1 つ以上の追加の PostgreSQL インスタンス 外部データベースサーバー インフラストラクチャの概要

36 ハードウェアインフラストラクチャ Cloudera CDP Data Center on Dell EMC Infrastructureは Dell EMCの最新のスイッチおよびサーバーソリューションを使用しています 以下を参照してください ネットワークアーキテクチャ (29ページ) Dell EMC PowerEdgeラックサーバーハードウェア構成 (34ページ) この章に示す構成は ノード仕様やストレージおよびネットワーク構成を含め CDP Data Centerをサポートするための選択肢を示すことを目的としており また 将来行われる可能性のあるCDP Private Cloudへのアップグレードとおおむね互換性を持つようにも設計されています ここに示す以外の選択肢と構成も可能です 以下の場合は デル テクノロジーズのセールススペシャリストにご連絡ください インフラストラクチャの計画と設計を支援いたします 後でCDP Private Cloudにアップグレードすることを具体的に計画している場合 Ozoneの本番運用後にそれを導入することを計画している場合 お客様の状況に固有の設計の選択肢について話し合いたい場合 ネットワークアーキテクチャ クラスターネットワークは 冗長性と管理機能へのアクセスを実現しながら ハイパフォーマンスで拡張性の高いクラスターのニーズを満たすように設計されています アーキテクチャは 25 GbEネットワークテクノロジーに基づくリーフアンドスパインモデルです リーフにはDell EMC PowerSwitch S5248F-ONスイッチが使用され スパインにはDell EMC PowerSwitch Z9100-ONまたはZ9264F-ONスイッチが使用されます ネットワーク層にはIPv4が使用されます 現時点では このアーキテクチャはネットワーク接続にIPv6を使用することをサポートも許可もしていません 図 9. クラスター論理ネットワーク (26ページ) は ネットワークアーキテクチャを示しています ネットワークインフラストラクチャの推奨事項 クラスターネットワーキングには PowerSwitchハードウェアを使用することをお勧めします Dell EMC PowerSwitchネットワーキングの特長は次のとおりです 分離型のハードウェア / ソフトウェア切り替えソリューション Open Network Install Environment(ONIE) のサポート 代替ネットワークオペレーティングシステムのゼロタッチインストールを可能にしますデータセンターファブリックのオーケストレーションと自動化をシンプルにするためのネットワークオペレーティングシステムの選択 オープンソースとLinuxベースの両方のアプリケーションとツールの幅広いエコシステム ネットワークを最適化および管理するための豊富なオプションを提供します Dell EMCの大容量ネットワークファブリック コストパフォーマンスに優れ 導入が容易であり ソフトウェアデファインドデータセンターへの明確な道筋を示します トップオブラック (ToR) ミドルオブロー(MoR) エンドオブロー(EoR) タイプの導入環境で 25/40/50/100 GbEの導入に必要な高密度を実現します Dell EMC Networking OS10 Enterprise Editionは 図 10. Dell EMC Networking OS10 (30ページ) に示すように 複数のアーキテクチャと環境をサポートするネットワークオペレーティングシステムです インフラストラクチャの概要

37 OS10により ネットワーク機能を多層構造に分離できます オープンソースへのOS10の貢献により ユーザーは独自のサードパーティー製ネットワーキング モニタリング 管理 およびオーケストレーションアプリケーションを柔軟に選択できます OS10 Enterprise Editionは CLIやSNMPなどの確立されたノースバウンドインターフェイスを介して 標準のL2およびL3プロトコルを備えた強化版のネットワークスタックをバンドルしています Switch Abstraction Interface(SAI) およびControl Plane Services(CPS) の抽象化レイヤーは 以下を実現します ネットワークプロセッシングユニット (NPU) での機能分離 Linuxカーネル上に記述されたソフトウェアアプリケーションの機能分離 図 10. Dell EMC Networking OS10 ネットワークファブリックアーキテクチャ クラスターネットワークは 冗長性と管理機能へのアクセスを実現しながら ハイパフォーマンスで拡張性の高いクラスターのニーズを満たすように設計されています アーキテクチャは 25 GbEネットワークテクノロジーに基づくリーフアンドスパインモデルです リーフにはDell EMC PowerSwitch S5248F-ONスイッチが使用され スパインにはDell EMC PowerSwitch Z9100-ONスイッチが使用されます ネットワーク層にはIPv4が使用されます このアーキテクチャはネットワーク接続にIPv6を使用することをサポートも許可もしていません また サーバーはiDRACポートによって1 GbE 管理スイッチに接続され idracインターフェイスへの帯域外アクセスを提供します サーバーノード接続 データネットワーク用ネットワークスイッチへのサーバー接続には Ethernetテクノロジーが使用されます クラスター内のすべてのデータ接続で 業界標準の25 GB Ethernetネットワークが使用されます Dell EMC PowerEdge R740xdおよびDell EMC PowerEdge R640サーバーに導入する場合は このテクノロジーを使用することをお勧めします エッジノードには 利用可能なネットワーク接続がもう1つあります この接続により これらのノードで実行されているアプリケーションとオプションのエッジネットワーク間のハイパフォーマンスクラスターアクセスが容易になります BMCネットワークへのサーバー接続では idracポートから各ラックのs3048-on 管理スイッチへの単一接続が使用されます インフラストラクチャの概要

38 ネットワークファブリック クラスター内のすべてのデータ接続で 業界標準の25 GB Ethernetネットワークが使用されます Dell EMC PowerEdge R740xdおよびDell EMC PowerEdge R640サーバーに導入する場合は このテクノロジーを使用することをお勧めします 単一ポッドよりも大規模なクラスターには 集約レイヤーが必要です 集約レイヤーは レイヤー 2(L2) またはレイヤー 3(L3) のいずれかで実装できます 初期のサイズと計画される拡張によって選択は変わります レイヤー 2は 低コストと中程度の拡張性が必要な場合に推奨され 約 250ノードをサポートできます レイヤー 3の集約は以下の場合に推奨されます 250ノードを上回る大規模の初期導入環境約 1,500ノードへの究極のスケールアップが計画されている導入環境クラスターを複数の異なるラック内の他のアプリケーションと同じ場所に設置する必要がある場合拡張性は 使用するスイッチとオーバーサブスクリプション率によって異なり クラスターノード数 (27ページ) に要約されています 以下のセクションではファブリックについて詳しく説明します 25 GbEポッドスイッチ (31ページ) 25 GbEクラスター集約スイッチ (32ページ) 25 GbE ポッドスイッチ各ポッドは Dell EMC PowerSwitch S5248F-ONを第 1レイヤースイッチとして使用します メモ : ポッドスイッチは トップオブラック (ToR) スイッチと呼ばれることがよくあります ただし このアーキテクチャでは 物理ラックを論理ポッドから分割します S5248F-ONは ハードウェアとソフトウェアの分離型データセンター固定スイッチです このスイッチは 高密度 25/100GbEポートを使用して フルデュープレックスでスループット4.0 Tbpsの累積帯域幅を実現でき 以下の要素で構成されています 100 GbEポートx 2(QSFP28-DD) 100 GbEポートx 4(QSFP28) 25 GbEポートx 48(QSFP28) Dell EMC PowerSwitch Z9100-ONは ハイパフォーマンスかつ超低レイテンシーのデータセンター要件に最適化された マルチレート100 GbE 1Uスパインスイッチです PowerSwitch Z9100-ONは すべてのポートからのラインレートトラフィックでスループット7.4 Tbpsの累積帯域幅を実現し 最大構成は次のとおりです 100 GbEポートx 32(QSFP28) 50 GbEポートx 64(QSFP+) 40 GbEポートx 32(QSFP+) 25 GbEポートx 128(QSFP+) 10 GbEポートx 図 GbE 単一ポッドネットワーク機器 (31ページ) は Dell EMC PowerSwitch S5248F-ONスイッチがポッドトラフィックを集約している単一ポッドネットワーク構成を示しています インフラストラクチャの概要

39 図 GbE 単一ポッドネットワーク機器単一ポッドの場合 ToRスイッチはクラスター全体の集約レイヤーとして機能できます 複数ポッドクラスターの場合は スパインレイヤーが必要です このアーキテクチャでは スイッチングの観点から 各ポッドが個別のエンティティとして管理されます 個々のポッドToRスイッチは スパインスイッチにのみ接続します 25 GbE クラスター集約スイッチ複数のポッドで構成されるクラスターの場合 このアーキテクチャでは スパインスイッチにDell EMC PowerSwitch Z9100-ONが使用されます PowerSwitch Z9100-ONは レイヤー 2とレイヤー 3の両方の実装に使用できます レイヤー 2 クラスター集約図 GbE 複数ポッドネットワーク機器 (32ページ) は Z9100- ONをレイヤー 2ネットワークのクラスタースパインスイッチとして使用する複数ポッドクラスターの構成を示しています 各 S5248F-ONポッドスイッチから集約レイヤーへのアップリンクは ボンディング構成で6 個の100 GbEインターフェイスを使用し 各ポッドから600 Gbの総帯域幅を実現します インフラストラクチャの概要

40 図 GbE 複数ポッドネットワーク機器 レイヤー 3 クラスター集約 Dell EMC PowerSwitch Z9100-ONコアスイッチは 25 GbEを使用する大規模クラスターのレイヤー 3での集約にも使用できます このアーキテクチャは ECMPとリーフ / スパイン組織に基づいて レイヤー 3 集約を使用するクラスターに別のネットワークアーキテクチャを使用します この構成では クラスターをノード数 1,500 以上まで拡張でき ポッドあたりのオーバーサブスクリプション率は3:1と低くなります 図 13. レイヤー 3 ECMPを使用した複数ポッドビュー (32ページ) は レイヤー 3およびECMPルーティングを使用した複数ポッドクラスターの場合の代替構成を示しています 図 13. レイヤー 3 ECMP を使用した複数ポッドビューレイヤー 3リーフ / スパインの導入の詳細については Dell EMC TechCenterドキュメントの リーフスパイン導入および新規導入のベストプラクティスガイド を参照してください idrac 管理ネットワーククラスターデータネットワークに加えて idrac( またはBMC) ネットワークという別のネットワークがクラスター管理用に提供されています インフラストラクチャの概要

41 idrac 管理ポートはすべて 専用 VLANを備えたラックごとのDell EMC PowerSwitch S3048-ONスイッチに集約されます この集約により ハードウェアのプロビジョニングと管理のための専用 idracまたはbmcネットワークが提供されます このネットワークには スイッチ管理ポートも接続されています 帯域外管理が必要な場合は 管理スイッチをコアに接続するか 専用の管理ネットワークに接続できます コアネットワーク統合集約レイヤーは クラスターのネットワークコアとして機能します ほとんどの場合 図 GbE 複数ポッドネットワーク機器 (32ページ) に示すように クラスターは企業内のより大規模なコアに接続しています Dell EMC PowerSwitch Z9100-ONでは 2 個の100 GbEポートがコアへの接続用に予約されています 接続の詳細はサイトに固有であり 導入計画の一環として決定する必要があります レイヤー 2 とレイヤー 3 の分離レイヤー 2とレイヤー 3の境界は ポッドまたは集約レイヤーのいずれかで分かれています どちらのオプションも同等に実行可能です このアーキテクチャは クラスター内のスイッチにレイヤー 2を使用します 図 13. Multiple pod view with Layer 3 ECMP (32ページ) の青と緑は レイヤー 2とレイヤー 3の境界を表しています 25 GbE ネットワーク機器の概要クラスターに必要なケーブルの数は以下にまとめられています 表 10. ラックあたりのネットワーク機器 (33ページ) 表 11. ポッドあたりのネットワーク機器 (33ページ) 表 12. クラスターあたりの集約ネットワークスイッチ ( 複数ポッドの場合 ) (33ページ) 表 10. ラックあたりのネットワーク機器 コンポーネント 数量 合計ラック数 1( 通常は12ノード ) 管理スイッチ One Dell EMC PowerSwitch S3048-ON x 1 スイッチインターコネクトケーブル 1 GbEケーブルx 1( 次のラックの管理スイッチと接続 ) 表 11. ポッドあたりのネットワーク機器 コンポーネント 数量 合計ラック数 3(36ノード ) トップオブラック (ToR) スイッチ Dell EMC PowerSwitch S5248F-ON x 2 ポッドアップリンクケーブル 100 Gb QSFP+ ケーブル x 4( 集約スイッチと接続 ) 表 12. クラスターあたりの集約ネットワークスイッチ ( 複数ポッドの場合 ) コンポーネント 数量 合計ポッド数 8 集約レイヤースイッチ Dell EMC PowerSwitch Z9100-ON x 2 インフラストラクチャの概要

42 必要なクラスターネットワーク機器の概要は 表 13. ノードあたりの必要なネットワークケーブル数 (33 ページ ) に示すとおりです 表 13. ノードあたりの必要なネットワークケーブル数 説明 1 GbEケーブル QSFP+ を使用した25 GbE 接続 マスターノード ノードあたり1 ノードあたり2 エッジノード ノードあたり1 ノードあたり2 ワーカーノード ノードあたり1 ノードあたり2 メモ :25 GbE ノード接続では通常 QSFP+/Quad QSFP 間にブレークアウトケーブルを使用します ケーブル数は一般的に 表 13. ノードあたりの必要なネットワークケーブル数 (33 ページ ) に示す接続数の 4 分の 1 になります Dell EMC PowerEdge ラックサーバーハードウェア構成 Cloudera CDP Data Center on Dell EMC Infrastructure は Dell EMC PowerEdge R640 および Dell EMC PowerEdge R740xd サーバーをサ ポートします インフラストラクチャノード インストラクチャノードは重要なクラスターサービスをホストするために使用され その構成はダウンタイムを短縮し ハイパフォーマンスを提供するために最適 化されています サイズ設定オプションの推奨構成は 表 14. インフラストラクチャノード構成 (34 ページ ) に示すとおりです 表 14. インフラストラクチャノード構成 マシンの機能プラットフォームシャーシプロセッサー RAM ネットワークドーターカード起動構成ストレージコントローラー コンポーネント Dell EMC PowerEdge R640サーバー 2.5インチシャーシ 最大 10 個のハードドライブと3 個のPCIeスロットを搭載インテルXeon Gold G x 2 8C/16T 192 GBのRAM Mellanox ConnectX-4 LXデュアルポート10/25 GbE SFP28 rndc PERCコントローラーから Dell EMC PERC H740P RAIDコントローラー 8 GB NVキャッシュ ディスク - スピンドル 1 TB 7.2 K RPM SATA 6 Gbps 512n 2.5インチx 8 ディスク - SSD 800 GB SSD SAS Mixed Use 12 Gbps 512e 2.5インチx 2 インフラストラクチャノード ( マスターノード1 マスターノード2 マスターノード3 エッジノード ) は 利用可能なすべてのドライブを使用し 複数のパーティションとファイルシステムで構成されています 各パーティションは パフォーマンスと信頼性のために最適化されています これらのマシンには 以下の表に示すディスクボリュームとパーティションのレイアウトを使用することをお勧めします 表 15. Dell EMC PowerEdge R640インフラストラクチャノードボリューム (34ページ) 表 16. Dell EMC PowerEdge R640インフラストラクチャノードパーティション (34ページ) インフラストラクチャの概要

43 表 15. Dell EMC PowerEdge R640 インフラストラクチャノードボリューム 物理ディスク数用途ボリュームタイプ 2 3 オペレーティングシステム RAID 1 0 ZooKeeper ジャーナルパススルー SSD 1 NameNode ジャーナルパススルー SSD 4 5 HDFS メタデータ RAID データベースストレージ RAID 10 表 16. Dell EMC PowerEdge R640 インフラストラクチャノードパーティション ( 続き ) ディスクパーティションマウントポイントサイズファイルシステム タイプ 説明 2 台のディスク RAID 1 プライマリー /boot 1024 MB ext4 ディスクの最初の 2 GB 以内にある必要がある BIOS ブート ファイルを含んでいます 2 台のディスク RAID 1 2 台のディスク LVM / 100 GB ext4 ルートファイルシステム LVM swap 4 GB swap オペレーティングシステムの swap 用パーティション RAID 1 2 台のディスク LVM /home 1 GB ext4 ユーザーホームディレクトリー RAID 1 2 台のディスク LVM /var すべての空 ext4 システムログファイル データベース メールとプリンターのス RAID 1 き領域 プールディレクトリー 一時ファイルと暫定的ファイルなどの 可変データを含んでいます SSD 1 プライマリー /journal/zooke eper 800 GB ext4 ZooKeeper データログディレクトリー (datalogdir) 通常 パスは /var/lib/zookeeper ですが /journal/zookeeper になりました SSD 2 4 台のディスク RAID 10 プライマリー プライマリー /journal/dfs 800 GB ext4 NameNodeはディレクトリー (dfs.namenode.edits.dir) を編集します 通常 パスは /data/1/dfs/nnですが / journal/dfs/nnになりました デフォルトはdfs.name.dirと同じになり 変更する必要があります /var/lib/pgsql 2 TB ext4 データベース用の運用データディレクトリー PostgreSQL データディレクトリー (PGDATA) は通常 /var/lib/pgsql であるため このディレクトリーには主にCloudera Managerデータベースが含まれています PostgreSQLの データファイルをこのディレクトリーに格納するには PostgreSQLの代替手段を構成する必要があります ワーカーノード ワーカーノードは コンピューティングとストレージを組み合わせた クラスターの主力要素です 意図するワークロードに応じて ストレージ中心負荷 コンピューティング中心負荷 または混在負荷に合わせて最適化できます CDP Data Centerは さまざまなハイブリッドソリューションをサポートしています これらのソリューションでは コンピューティングタスクがデータストレージから分離されており リモートクラスターからデータにアクセスすることが可能です このアーキテクチャは 次の3つの代替ワーカーノード構成を提供します インフラストラクチャの概要

44 ストレージ中心 汎用 ディープストレージ 処理負荷の軽いストレージ中心クラスター向け この構成はハイブリッドソリューションのクラスターを対象としています 重いワークロード 大容量メモリー コンピューティング要件を持つクラスター向け ストレージ要件の大きい大規模クラスター向け この構成は クラスター内のノードあたりストレージの実質的な制限に近いものです ワーカーノードの推奨構成は以下に示されています 表 17. ストレージ中心サーバー構成 (35ページ) 表 18. 汎用サーバー構成 (36ページ) 表 19. ディープストレージサーバー構成 (36ページ) これらのオプションは データ用にラージフォームファクター (LFF)3.5インチドライブを使用する2Uシャーシ構成であり ハイパフォーマンスコンピューティングとソリッドステートストレージを備えた高密度ストレージ機能を提供して 一時データの高速キャッシュを実現します 表 17. ストレージ中心サーバー構成 マシンの機能プラットフォームシャーシプロセッサー RAM ネットワークドーターカードブート構成ストレージコントローラー ワーカーノード Dell EMC PowerEdge R740xdサーバー BPに12 個の3.5インチHDDとFlexBbayに4 個の2.5インチHDDを搭載したシャーシインテルXeon Gold G x 2 8C/16T 192 GBのRAM Mellanox ConnectX-4 LXデュアルポート10/25 GbE SFP28 rndc BOSSコントローラーカードから Dell EMC HBA330コントローラー 12 Gbps Minicard ディスク - スピンドル 4 TB 7.2 K RPM SATA 6 Gbps 512n 3.5 インチ x 12 ディスク - SSD 800 GB SSD SAS Mixed Use 12 Gbps インチ x 4 表 18. 汎用サーバー構成 マシンの機能 プラットフォーム シャーシ ワーカーノード Dell EMC PowerEdge R740xdサーバー BPに12 個の3.5インチHDDとFlexBbayに4 個の2.5インチHDDを搭載したシャーシ プロセッサーインテル Xeon Gold 6246R 3.4 G 16C/32T x 2 RAM 384 GB の RAM ネットワークドーターカード ブート構成 ストレージコントローラー Mellanox ConnectX-4 LX デュアルポート 10/25 GbE SFP28 rndc BOSS コントローラーカードから Dell EMC HBA330 コントローラー 12 Gbps Minicard ディスク - スピンドル 4 TB 7.2 K RPM SATA 6 Gbps 512n 3.5 インチ x 12 ディスク - SSD 800 GB SSD SAS Mixed Use 12 Gbps インチ x 4 インフラストラクチャの概要

45 表 19. ディープストレージサーバー構成 マシンの機能プラットフォームシャーシプロセッサー RAM ネットワークドーターカードブート構成ストレージコントローラー ワーカーノード Dell EMC PowerEdge R740xd2サーバー 3.5インチHDD 24 個と3.5インチリアHDD 2 個を搭載したシャーシインテルXeon Gold G x 2 20C/40T 384 GBのRAM Mellanox ConnectX-4 LXデュアルポート10/25 GbE SFP28 rndc BOSSコントローラーカードから Dell EMC HBA330コントローラー 12 Gbps Minicard ディスク - スピンドル 4 TB 7.2 K RPM NLSAS 12 Gbps 512n 3.5 インチ x 24 ディスク - SSD 800 GB SSD SAS Mixed Use 12 Gbps インチ x 2 表 20. Dell EMC PowerEdgeワーカーノードボリューム (36ページ) に示すディスクおよびパーティションレイアウトをワーカーノードに対して使用するこ とをお勧めします 表 20. Dell EMC PowerEdgeワーカーノードボリューム 仮想ディスク パーティションマウントポイント サイズ ファイルシステムタイプ 説明 DellBOSS 1 プライマリー /boot 1074 MB ext4 BIOSブートファイルの内容は ディスクの先頭から2 GBの領域に書き込まれている必要があります DellBOSS 2 LVM / 100 GB ext4 ルートファイルシステム DellBOSS 3 LVM swap 4 GB swap オペレーティングシステムのswap 用パーティション DellBOSS 4 LVM /home 1 GB ext4 ユーザーホームディレクトリー DellBOSS 5 LVM /var GB ext4 以下のような可変データを含んでいますシステムログファイルデータベースメールおよびプリンタースプールディレクトリー sda sdb sdn ssd1 a プライマリープライマリープライマリープライマリー 一時ファイルと暫定的ファイル /data/ GB ext4 HDFSデータを含んでいます /data/ GB ext4 HDFSデータを含んでいます /data/n 4096 GB ext4 HDFSデータを含んでいます /datassd/ GB ext4 以下をはじめとした格納済みデータを含んでいます 階層型 HDFSストレージ Sparkのキャッシュ MapReduceのテンポラリーファイル HBaseの階層型キャッシュ インフラストラクチャの概要

46 表 20. Dell EMC PowerEdge ワーカーノードボリューム ( 続き ) 仮想ディスクパーティションマウントポイントサイズファイルシステム タイプ 説明 ssd2 a ssd3 a ssd4 a プライマリー プライマリー プライマリー /datassd/ GB ext4 以下をはじめとした格納済みデータを含んでいます階層型 HDFSストレージ Sparkキャッシュ MapReduce 一時ファイル HBase 階層型キャッシュ /datassd/ GB ext4 以下をはじめとした格納済みデータを含んでいます 階層型 HDFSストレージ Sparkキャッシュ MapReduce 一時ファイル HBase 階層型キャッシュ /datassd/ GB ext4 以下をはじめとした格納済みデータを含んでいます 階層型 HDFSストレージ Sparkキャッシュ MapReduce 一時ファイル HBase 階層型キャッシュ a. 大規模サーバー構成では 階層型 HDFS ストレージとキャッシュに 2 台の SSD ドライブを使用します ユーティリティーノード ユーティリティーノードは Cloudera Manager や Hive Metastore などのマスタープロセスではない他のクラスタープロセスを実行します ユーティリティーノードの推奨構成は 表 21. ユーティリティーノード構成 (37 ページ ) に示すとおりです 表 21. ユーティリティーノード構成 マシンの機能プラットフォームシャーシプロセッサー RAM ネットワークドーターカードブート構成ストレージコントローラー ユーティリティーノード Dell EMC PowerEdge R640サーバー 2.5インチシャーシ 最大 10 個のハードドライブと3 個のPCIeスロットを搭載インテルXeon Gold G x 2 8C/16T 192 GBのRAM Mellanox ConnectX-4 LXデュアルポート10/25 GbE SFP28 rndc PERCコントローラーから Dell EMC PERC H740P RAIDコントローラー 8 GB NVキャッシュ ディスク - スピンドル 1 TB 7.2 K RPM SATA 6 Gbps 512n 2.5 インチ x 8 ディスク - SSD 800 GB SSD SAS Mixed Use 12 Gbps 512e 2.5 インチ x 2 インフラストラクチャの概要