hadoopクラスタマシンにメモリを追加するメンテナンスプロセス
前期のクラスタ計画の問題により,現在のHadoopクラスタにおけるハードウェアが完全に利用されていない.現在のマシンのメモリCPU比率は2 G:1 coreであるが、一般的なMapReduceタスク(データ量処理が大きく、論理が複雑)のMR両端に4 G近くのメモリが必要であるため、従来のボトルネックはメモリが大きくないことであり、週末にはメンテナンス部門とともに現在のクラスタのマシンメモリ操作を実行する(私はここで主に醤油+学習を行い、メンテナンスの経験が不足している).
メモリは、NameNodeに関係なく現在のすべてのDataNodeノードを対象としており、操作前にすべてのDataNodeノードを整理する必要があります.
DataNodeノードのメモリの追加は、現在のオンラインタスクの正常な実行に影響を与えることはできません.そのため、メモリの追加操作をシリアルで実行する必要があります(本来はそうですが、ほとんどのタスクの実行に影響を及ぼし、HDFS上のファイルがこの間にアクセスできることを保証するしかありません).
各ノードに対するアクションの具体的な手順は、次のとおりです.
DataNodeノードのDataNodeおよびNodeManagerサービスを停止します. ノードを停止します. 機械室の人員にメモリを追加するように通知し、システムは8 Gを予約する必要がある. 機械室の人員がメモリの追加に成功した後、DataNodeノードの起動を通知します. の再起動が完了したら、サーバメモリの追加に成功したかどうかを確認し、ハードディスクのマウント情報が正常であることを確認します(df-u、正しくマウントされていない場合は、/etc/rc.localのmountコマンドを手動で実行します). hadoopの各ディレクトリの権限とフォルダが正しいかどうかを確認し、すべて正常になったら、hadoopメモリプロファイル(yarn-site.xmlのyarn.nodemanager.resource.memory-mbパラメータ)を変更します. 関連hadoopサービスを開始する:nodemanagerとDataNodeサービス;
リセットが完了したら、一部のサービスがアクセスできないようにファイアウォールを確認します.
もちろん、すべての操作が順調な状況ですが、これらの操作が完了する前に、最悪の状況を考慮する必要があります.メモリバーのインストールに失敗したらどうしますか?ロールバック操作が必要で、マシンを再起動し、再起動できない場合はシステムを再インストールする必要があり、DataNodeのデータが失われる可能性があります.このような状況が2台の機器で発生した場合、直ちに後続のアップグレード操作を停止する(HDFSのデフォルトreplicationは3).
クラスタのリカバリが予定されていない場合は、すべての関係者に原因と折衷案を通知し、リカバリ操作をできるだけ早く実行する必要があります.
メモリを交換して機械を止める時、MRを走る任務を行うことができなくて、blockが失敗した情報を読み取ることが発生する可能性があるためです:
今回はまだ週末に操作していたので、影響は少し小さいですが、オンラインで走るタスクはほとんど失敗し、hadoopの失敗タスクノードの判断も失敗したと思います.すべてのDataNodeがアップグレードしたからです.まとめてみると、平日にこの操作を行うと、プロセス全体を少し長くして、毎日1台のマシンのメモリを追加することができます.これにより、クラスタが少なく、1台のマシンがオンラインタスクに与える影響が小さくなり、タスクが失敗しすぎません.
メモリは、NameNodeに関係なく現在のすべてのDataNodeノードを対象としており、操作前にすべてのDataNodeノードを整理する必要があります.
DataNodeノードのメモリの追加は、現在のオンラインタスクの正常な実行に影響を与えることはできません.そのため、メモリの追加操作をシリアルで実行する必要があります(本来はそうですが、ほとんどのタスクの実行に影響を及ぼし、HDFS上のファイルがこの間にアクセスできることを保証するしかありません).
各ノードに対するアクションの具体的な手順は、次のとおりです.
リセットが完了したら、一部のサービスがアクセスできないようにファイアウォールを確認します.
もちろん、すべての操作が順調な状況ですが、これらの操作が完了する前に、最悪の状況を考慮する必要があります.メモリバーのインストールに失敗したらどうしますか?ロールバック操作が必要で、マシンを再起動し、再起動できない場合はシステムを再インストールする必要があり、DataNodeのデータが失われる可能性があります.このような状況が2台の機器で発生した場合、直ちに後続のアップグレード操作を停止する(HDFSのデフォルトreplicationは3).
クラスタのリカバリが予定されていない場合は、すべての関係者に原因と折衷案を通知し、リカバリ操作をできるだけ早く実行する必要があります.
メモリを交換して機械を止める時、MRを走る任務を行うことができなくて、blockが失敗した情報を読み取ることが発生する可能性があるためです:
Error: org.apache.hadoop.hdfs.BlockMissingException:
Could not obtain block: BP-714842383-192.168.7.11-1393991369860:blk_1098537659_1099556437863 file=xxx
at org.apache.hadoop.hdfs.DFSInputStream.chooseDataNode(DFSInputStream.java:838)
at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:526)
at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:749)
at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:793)
at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:601)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.moveToNext(MapTask.java:197)
at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.next(MapTask.java:183)
at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:52) at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:429)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341)
at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:162)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:157)今回はまだ週末に操作していたので、影響は少し小さいですが、オンラインで走るタスクはほとんど失敗し、hadoopの失敗タスクノードの判断も失敗したと思います.すべてのDataNodeがアップグレードしたからです.まとめてみると、平日にこの操作を行うと、プロセス全体を少し長くして、毎日1台のマシンのメモリを追加することができます.これにより、クラスタが少なく、1台のマシンがオンラインタスクに与える影響が小さくなり、タスクが失敗しすぎません.