CDHビッグデータ環境を積極的にインストールする方法（個人的な意見を含む）

翻訳元：ハウツー：Apache Hadoopクラスターをボスのようにデプロイする
ソース記事のリンク：https：//blog.cloudera.com/how-to-deploy-apache-hadoop-clusters-like-a-boss/

前書き

       これは15年のブログであることがわかりますが、ビッグデータをインストールする際の基本的な考慮事項として、これを参照しています。個人的にはとても良いと感じています。Baiduは翻訳版を見つけていないようです。私自身の経験に基づいて自由に書いてください。元の英語版または上部のリンクによって異なります。
       この記事では、ビッグデータ環境を構築する方法について具体的に説明していませんが、将来変更が必要な問題を回避できる重要なシステムとハードウェアの最適化に焦点を当てています。これは、構築を完了したばかりの、または構築しようとしている友人に適しています。 。

Hadoopプロダクションの成功を最大化し、継続的な長期調整を最小化する方法でHadoopクラスターをセットアップする方法を学びます。

       以前、ApacheHadoop展開用の新しいハードウェアの選択に関していくつかの推奨事項を発行しました。この記事では、ワークロード分析やCPU、ディスク、メモリの割り当てに関する一般的な推奨事項など、クラスターの計画と展開に関するいくつかの重要なアイデアについて説明しました。この記事では、実装プロセスの次の部分である、到着後にマシンを構成するためのいくつかのベストプラクティスとガイドラインを提供します。これらの2つの記事の間で、Hadoopが生産を拡大するための良い出発点になります。
       具体的には、ネットワーク、ディスク、およびホストが適切に構成されていることを確認するために行う必要のあるいくつかの重要な決定について説明します。また、データを効率的に使用し、データセットの拡張に伴う問題を最小限に抑えるために、ディスクとサービスを配置する方法についても説明します。

ネットワークモジュール：すべてのSYNが許されますように

       ホスト名解決スキーム、DNSおよびFQDNDataNodeなどのHadoopJava
       プロセスは、その上で実行されているホストのホスト名を取得し、ルックアップを実行してIPアドレスを決定します。次に、このIPを使用して、DNSサービスまたはローカルの/ etc / hostsに格納されている正規名を判別します。各ホストは、独自のホスト名で順方向ルックアップを実行でき、独自のIPアドレスを使用して逆方向ルックアップを実行できる必要があります。さらに、クラスター内のすべてのホストは他のホストを解決する必要があります。Linux hostコマンドを使用して、順方向および逆方向のルックアップが正しく構成されていることを確認できます。

$ host `hostname`
bp101.cloudera.com has address 10.20.195.121
$ host 10.20.195.121
121.195.20.10.in-addr.arpa domain name pointer bp101.cloudera.com

Cloudera Managerは、単純なpythonコマンドを使用して分析をテストします

$ python -c 'import socket; print socket.getfqdn(), socket.gethostbyname(socket.getfqdn())'

       このステップでは/ etc / hostsに依存したいのですが、代わりにDNSを使用することをお勧めします。ホストファイルを使用する場合と比較して、DNSはエラーが発生しにくく、変更の実装が容易になります。ホスト名は、完全修飾ドメイン名（FQDN）に設定する必要があります。Kerberosを使用するにはFQDNを使用する必要があることに注意することが重要です。これは、TLS暗号化やKerberosなどのセキュリティ機能を有効にするために重要です。次のコマンドを使用して確認できます。

$ hostname --fqdn
bp101.cloudera.com

       / etc / hostsファイルを制御に使用している場合は、それらを適切な順序で配置してください。

192.168.2.1 bp101.cloudera.com bp101 master1
192.168.2.2 bl102.cloudera.com bp102 master2

ネームサーバーキャッシュ

       Hadoopは、DNS、NIS、LDAPなどのネットワークベースのサービスを広く使用しています。ネットワーク障害を軽減し、共有インフラストラクチャへのプレッシャーを軽減し、名前解決の遅延を改善するには、ネームサーバーキャッシュデーモン（nscd）を有効にすることが役立つ場合があります。nscdは、ローカル呼び出しとリモート呼び出しの両方の結果をメモリにキャッシュし、通常、潜在的なネットワークラウンドトリップを回避します。ほとんどの場合、nscdを有効にして機能させてから、そのままにしておくことができます。Red Hat System SSSDプロトコルを実行している場合は、nscd構成を変更する必要があります。SSSDが有効になっている場合は、nscdを使用してpasswd、group、またはnetgroup情報をキャッシュしないでください。
ゲートウェイ機器のリンク集約（LINK AGGREGATION）
       は、NICボンディングまたはNICグループ化とも呼ばれ、ネットワークインターフェイスを組み合わせてスループットまたは冗長性を向上させることを意味します。正確な設定は環境によって異なります。
       インターフェイスをバインドするには、さまざまな方法があります。一般に、可用性よりもバインディングスループットをお勧めしますが、このトレードオフは、インターフェイスの数と内部ネットワーク戦略に大きく依存します。NICボンディングは、Clouderaの設定ミスの最も高度な要因の1つです。通常、ボンディングを有効にする前に、クラスターを有効にしてすべての作業を確認することをお勧めします。これにより、発生する可能性のある問題を解決できます。

個人的な意見：独自のコンピュータールームを構築する場合は、1つまたは2つのゲートウェイのコストを気にする必要はありません。リンク集約は依然としてスループットに非常に効果的です。特にデータ量がますます大きくなっている今、スイッチのトラフィックがあなたを制限しないようにしてください。物理マシンの10ギガビットポート。

仮想ローカルエリアネットワーク（VLAN）

       VLANは必須ではありませんが、ネットワークの観点からは、VLANによって作業が簡単になります。ネットワーク上の他のトラフィックをできるだけ多く利用するために、実稼働展開専用のスイッチングインフラストラクチャに移行することをお勧めします。次に、トラブルシューティングと分離を容易にするために、すべてのHadoopトラフィックが1つのVLAN上にあることを確認します。

個人的な意見：自作のIDCの場合は、ホストを配置するときにラックが敏感であり、マスターをできるだけ開いて、VLANを大きくする必要があることに注意してください。クラスターの場合、内部を細かく分割する必要はありません。 。

オペレーティングシステム（OS）

       Cloudera Managerは、オペレーティングシステム構成の既知の一般的な問題を適切に特定しますが、以下を再確認してください。

ファイアウォール（IPTABLES）

       一部のお客様は、クラスターの初期設定でIPTABLESを完全に無効にしました。もちろん、管理の観点からは、これは物事を簡単にしますが、いくつかのリスクももたらします。クラスタ内のデータの機密性によっては、IPTABLESを有効にすることをお勧めします。Hadoopは、多くのエコシステムコンポーネントを介して通信するために多くのポートを必要としますが、ドキュメントはそれを構成するのに役立ちます。
添付のCDHポートの公式テーブルリンク：https：//docs.cloudera.com/documentation/manager/5-0-x/Cloudera-Manager-Installation-Guide/cm5ig_config_ports.html

個人的な意見：Iptbales、またはCentos7のデフォルトのfirewalldをオンにして、問題が発生しないように準備する必要があります。本当に怠け者の場合は、イントラネット上のすべてのポートを開くポリシーを設定できます。

SELINUX

       Hadoopエコシステムのさまざまなコンポーネントをすべて管理するSELINUX戦略を構築することは困難であるため、ほとんどのお客様はSELINUXを無効にして実行しています。SELINUXの実行に関心がある場合は、サポートされているOSバージョンであることを確認してください。出力をキャプチャしてニーズを満たす戦略を定義できるように、最初にのみライセンスモードを有効にすることをお勧めします。

個人的な意見：SELINUXは面倒なので、削除して無効にします。

スワップメモリ​​（SWAPPINESS）

       ワーカーノードの従来の推奨事項は、swappiness（vm.swappiness）を0に設定することです。ただし、この動作は新しいカーネルで変更されているため、1に設定することをお勧めします。（この記事には詳細があります。）

$ sysctl vm.swappiness=1
$ echo "vm.swappiness = 1" >> /etc/sysctl.conf

システム制限設定

       ほとんどのディストリビューションのデフォルトのファイルハンドル制限（つまりulimits）1024は、十分に高く設定されていない可能性があります。Cloudera Managerはこの問題を解決しますが、Cloudera Managerを実行していない場合は、この事実に注意してください。Cloudera Managerは、Hadoopのデフォルトの制限を超えてユーザー制限を変更しません。それでも、グローバル制限を64kに増やすことは依然として有益です。

透明な巨大ページ（THP）

       CDH 5でサポートされているほとんどのLinuxプラットフォームには、「透過的巨大ページ圧縮」と呼ばれる機能が含まれています。この機能は、Hadoopワークロードとの相互作用が不十分であり、パフォーマンスが大幅に低下する可能性があります。Red Hatは、バグは6.4以降のバージョンで修正されたと主張していますが、パフォーマンスの問題を引き起こす可能性のある残りがまだあります。さらにテストが可能になるまで、デフラグメンテーションを無効にすることをお勧めします。
さまざまなシステムのdefrag_file_pathnameのパスは次のとおりです。RedHat
/ CentOS：/ sys / kernel / mm / redhat_transparent_hugepage / defrag
Ubuntu / Debian、OEL、SLES：/ sys / kernel / mm / transparent_hugepage / defrag

$ echo 'never' > defrag_file_pathname

関連するステートメントを/etc/rc.localに追加することを忘れないでください。そうしないと、再起動が無効な場合に恥ずかしい思いをします。

タイムゾーン
       内の各サーバーは、NTPサービスをインストールし、それが利用可能であることを確認する必要があります

ストレージ

       クラスタのストレージを適切に構成することは、最も重要な最初のステップの1つです。これを適切に行わないと、構成を変更すると壊滅的であり、通常は現在のストレージレイヤーを完全にやり直す必要があるため、問題が発生します。

オペレーティングシステム、ログドライブ、データドライブ

       一般的な2Uマシンには、専用データドライブ用の16〜24のドライブベイと、オペレーティングシステムとログ専用の一部のドライブ（通常は2つ）が装備されています。Hadoopの設計原理は単純です：「ハードウェア障害」。このようにして、ディスク、ノード、さらにはラックの障害にも耐えることができます。（この原則は確かに大規模な分野で人気を博し始めていますが、それに直面しましょう。このブログを読んでいる場合は、GoogleやFacebookを利用していない可能性があります。）
       通常の人間規模（4,000ノード未満）でも、 Hadoopは、ボスのようなハードウェア障害の影響に耐えることができますが、これらの障害を減らすために冗長性を追加することは合理的です。一般的なガイドラインとして、OSドライブ（つまり、システムディスクのルートパスが配置されているハードディスク）にRAID-1（ミラーリング）を使用して、OSドライブが失われた場合にデータノードのカチカチという音を長時間維持することをお勧めします。この手順は絶対に必要というわけではありませんが、小規模なクラスターでは、ノードが失われると計算能力が大幅に低下する可能性があります。
       他のドライブは、RHEL6 +、Debian 7.x、またはSLES11 +を実行しているシステムで、個別にインストールされたext4パーティションを使用してJBOD（「ディスクの束」）で構成する必要があります。一部のハードウェアプロファイルでは、特定のコンピューター用に必須のRAIDコントローラーを構築する必要がある場合、単一のRAID-0ボリュームを使用する必要があります。この方法は、ドライブを単一のスピンドルとして取り付けるのと同じ効果があります。
       便利なマウントオプションがいくつかあります。これらの内容は、著者のAlexMoundalexisであるHadoopOperationsの本でよく紹介されていますが、ここで少し言及します。

ルートディレクトリの予約済みスペースの要件

       デフォルトでは、ext3とext4の両方が、特定のファイルシステム上のブロックの5％をrootユーザー用に予約します。HDFSデータディレクトリはこの予約を必要としませんが、パーティションを作成するとき、またはmkfsとtune2fsをそれぞれ使用した後に、ゼロに調整できます。

個人的な意見：0に調整することはお勧めしません。必要ありません。割り当てが妥当な場合、ルートディレクトリの実際のスペースは非常に小さくなります。非マスターノードがデータを保存せず、プログラムを配置するだけの場合は、通常の300Gハードディスクでも十分です。オリジナリティを尊重する場合は、リセットコマンドを放します

$ mkfs.ext4 -m 0 /dev/sdb1
$ tune2fs -m 0 /dev/sdb1

ファイルシステムのアクセス時間の構成

       Linuxファイルシステムは、各ファイルが最後にアクセスされた時刻を記録するメタデータを維持しているため、読み取りもディスクに書き込まれます。このタイムスタンプはatime（つまり、アクセス時間）と呼ばれ、Hadoop用に構成されたドライブでは無効にする必要があります。/ etc / fstabのマウントオプションを使用して設定します。

/dev/sdb1 /data1    ext4    defaults,noatime       0

設定が完了すると、再起動せずに有効になります。手順は次のとおりです。

mount -o remount /data1

ディレクトリ権限

       これはマイナーなポイントですが、データドライブをマウントする前に、ディレクトリのアクセス許可を700に変更することを検討する必要があります。したがって、ドライブがマウント解除されている場合、これらのディレクトリに書き込むプロセスはOSマウントをいっぱいにしません。

LVM、RAID、またはJBOD（3つのハードディスクの表示）

       JBOD構成、RAID構成、LVM構成のどれが必要かとよく聞かれます。Hadoopエコシステム全体の作成では、JBOD構成が考慮されます。HDFSは、シーケンシャル読み取りが長い大きなファイル用に設計された不変のファイルシステムです。このターゲットは、シーケンシャル読み取りを通じて最高のパフォーマンスを実現できるため、スタンドアロンSATAドライブでうまく機能します。つまり、RAIDは通常、既存のシステムに冗長性を追加するために使用されますが、HDFSには冗長性が組み込まれています。実際、HadoopでRAIDシステムを使用すると、パフォーマンスに悪影響を与える可能性があります。
       RAID-5とRAID-6はどちらも、RAIDストライプにパリティビットを追加します。これらのパリティビットは、標準操作中に読み書きする必要があり、多くのオーバーヘッドが追加されます。独立したSATAドライブは存在しないため、パリティビットを気にすることなく継続的に書き込み/読み取りを行います。対照的に、HDFSは複数の個別のマウントポイントを持つことを利用しており、ノードに障害が発生する前に単一のドライブ/ボリュームに障害が発生する可能性があります。これはHDFS並列I / Oの秘密ではありません。RAID-5またはRAID-6アレイでドライブをセットアップすると、ドライブの構成に応じて、単一のアレイまたはいくつかの非常に大きなマウントポイントのアレイが作成されます。これらのRAIDアレイは、データ保護のためのHDFSの自然なプロモーションを破壊し、シーケンシャル読み取り速度とマップタスクのデータローカリティを遅くします。
RAIDアレイは、多数のインストールポイントを必要とする他のシステムにも影響を与える可能性があります。たとえば、Impalaは、システム内のスピンドルごとにスレッドを追加します。大規模な単一のRAIDグループと比較すると、JBOD環境で優れたパフォーマンスを発揮します。同じ理由で、LVMでHadoopドライバーを構成する必要も推奨もされていません。

個人的な意見：要するに、システムディスクRAID1を除いて、可能な限りJBODを試してください。それが不可能な場合は、RAID0をLVMにすることはできません。！！

ハイブリッドハードウェアの展開

       多くのお客様は定期的に新しいハードウェアを購入しています。データとワークロードの量が増えるにつれて、新世代のコンピューティングリソースを追加することは理にかなっています。異種ディスク、メモリ、またはCPU構成を含むこのような環境では、Cloudera Managerでロールグループを使用できます。管理者はロールグループを使用して、各ノードまたは各ノードグループのメモリ、YARNコンテナ、およびCgroup設定を指定できます。
       もちろん、Hadoopはさまざまなハードウェア仕様で実行できますが、ワーカーノードの構成をできるだけ同じに保つことをお勧めします。分散コンピューティング環境では、ワークロードはさまざまなノードに分散されるため、ローカルデータアクセスを最適化するのが最適です。より少ないコンピューティングリソースで構成されたノードがボトルネックになる可能性があり、混合ハードウェア構成で実行すると、SLAウィンドウの変更が大きくなる可能性があります。考慮すべきことがいくつかあります。

• ハイブリッドハードディスク構成-デフォルトでは、HDFSブロックは、循環的に機能するようにdfs.data.dirで指定されたすべてのディレクトリに配置されます。たとえば、ノードに6つの1.2TBドライブと6つの600GBドライブがある場合、小さいドライブはより速くいっぱいになり、容量のバランスが崩れます。「空き領域」戦略を使用するには、追加の構成が必要です。この場合、ディスクの一部しか書き込んでいない可能性があるため、I / Oにバインドされたワークロードが影響を受ける可能性があります。この方法でドライブを展開することの意味を事前に知っておいてください。また、より全体的なストレージを備えたノードを展開する場合は、HDFSのバランスがパーセンテージであることに注意してください。
• 混合メモリ構成-ワーカーノードで使用可能なメモリを混合すると、追加の構成が必要になるため、問題が発生する可能性があります。
• 混合CPU構成-同じ概念。ジョブは最も遅いCPUによって制限される可能性があり、実際には、より新しい/より多くのコアを実行する利点が無効になります。
  上記の点を理解することは重要ですが、ClouderaManagerはさまざまなホストにリソースを割り当てるのに役立つことを忘れないでください。構成を簡単に管理および最適化できます。

  個人的な意見：特に全体のストレージ容量がいっぱいでない場合（85％以上）、ハードディスク構成の問題は大きくありませんが、メモリ周波数を含めると、CPUの計算能力は確かに一定の違いを引き起こしますが、障害がある必要はありません。 YARNの計算は、主に簡単な実行に基づいています。一般に、通常のシステム操作を前提として、シングルコアはそれほど悪くはありません。

横暴な構成CDHマネージャー（ボスのようなClouderaマネージャー）

       ClouderaManagerを使用してHadoopクラスターを管理することを強くお勧めします。Cloudera Managerは、生活を楽にするための多くの貴重な機能を提供します。Cloudera Managerのドキュメントはこれについて非常に明確ですが、あいまいさを排除するために、ClouderaManagerを使用して本番環境に対応したHadoopを展開するための高レベルの手順を次に示します。
1.外部データベースをセットアップし、展開に必要なアーキテクチャを事前に作成します。（MySQLのたとえば、パスワードを変更することを忘れないでください）
デフォルトの文字セットUTF8 AMONデータベースを作成し、
すべてのアモンの助成金は。TO'amon「@」％「のBY'amon_password IDENTIFIED」;
データベースRecovery Managerのデフォルトの文字セットUTF8を作成し、
すべてのRecovery Managerの助成金が。 TO 'rman' @ '％' IDENTIFIED BY'rman_password ';
create database metastore DEFAULT CHARACTER SET utf8;
grant all onmetastore。TO'metastore'@'％' IDENTIFIED BY'metastore_password ';
create database nav DEFAULT CHARACTER SET utf8;
grant all上のNAV。 TO'nav」
データベース歩哨を作成するDEFAULTCHARACTER SET utf8;
歩哨にすべてを付与します。* TO'sentry '@'％ 'IDENTIFIED BY'sentry_password';
（上記の例のパスワードを変更してください！）

2.ドキュメントに従って、cloudera-manager-serverおよびcloudera-manager-daemonsソフトウェアパッケージをインストールします。

yum install cloudera-manager-server cloudera-manager-daemons

元のテキストにはインストール手順が記載されていましたが、少し怠惰です。詳細については、最初に公式のインストールドキュメントを読むことができます。それでも、
ボーナスリンク（https://docs.cloudera.com/documentation/enterprise/release-notes）でかなり詳細になっていると思います。/topics/rg_release_notes.html

3. scm_prepare_database.shスクリプトを実行して、データベースタイプを判別します。

/usr/share/cmf/schema/scm_prepare_database.sh mysql -h cm-db-host.cloudera.com -utemp -ptemp --scm-host cm-db-host.cloudera.com scm scm scm

注：これは以前に作成されたものですが、新しいバージョンのCDHでは必ずしもこのスクリプトを使用する必要はありません。

4. Cloudera Manager Serviceを起動し、それ以降はウィザードに従います。
これは、Cloudera Managerをインストールする最も簡単な方法です。これにより、20分で
本番環境に対応した展開を開始できます。注：いわゆるウィザードは、マスターポート7180を起動した後のWebウィザードである必要があります。具体的なインストールについては、上記のリンクを参照してください。

役割を果たす：サービスレイアウトガイド

       Cloudera Managerベースの展開の場合、次の図は、ほとんどの構成のクラスター全体にサービスロールを展開するための合理的な方法を示しています。

       大規模なクラスター（50ノードを超える）では、5つの管理ノードに移動し、ResourceManagerとNameNodeのペアに専用ノードを使用する必要がある場合があります。さらに、Cloudera Manager、Hive Metastoreなどに外部データベースを使用することも珍しくなく、他のHiveServer2またはHMSサービスも展開できます。
       各管理ノードには128GB、作業ノードには256〜512GBをお勧めします。メモリは比較的安価であり、コンピューティングエンジンがメモリ内実行にますます依存するようになると、追加のメモリが完全に使用されます。
       詳細については、次の図で、さまざまなサービスストレージコンポーネントへの適切なディスクマッピングについて説明します。

       ここではClouderaManagerデータベースにLVMを指定しますが、RAID0も選択できます。
注：私はこの点に同意しません。データベースは実際には最もタブーです。RAID1を使用してください。

結論
       適切な知識があれば、Hadoopクラスターのセットアップは比較的簡単です。適切なインフラストラクチャを購入し、最初から正しく構成するために、余分な時間をかけてください。上記のガイドラインに従うと、Hadoopの展開で成功する可能性が最も高くなり、面倒な構成を回避できるため、上司などの実際のビジネス上の問題の解決に時間を集中できます。

個人的な意見：記事全体の多くは参照用に使用できます。非常に優れています。ほとんどの人のクラスターには数千のユニットがありません。これを参照して、特定の構成を作成できます。