摘要： 多租戶大數據集群對於企業而言是常見且必不可少的，以下是如何管理它們。
當您運行現代數據集群時，這對於企業來說變得越來越普遍和必不可少，您不可避免地會發現令人頭疼的問題。
通常，在單個群集上運行各種各樣的工作負載，這可能使其成為管理和運營的噩夢 - 類似於在繁忙的城市中管理流量。有對操作人在那裡誰有權管理在同一個集群上運行的Spark, Hive, impala and Kafka的應用程序，他們擔心每個應用程序的資源需求，集群工作負載的時間分配，優先級一個真正的痛苦每個應用程序或用戶，然後確保一切運行像一個可預測的良好的機器。
任何在資料運行工作的人有觀點在這裡，因為你毫無疑問已經花了無數的時間，一天又一天，學習巨大生產集群的行為洞察的發現如何改善性能，可預見性和穩定性。無論是運行批量作業的千節點Hadoop集群，還是運行AI，ML或某種類型的高級實時分析的500個節點Spark集群。或者，更有可能的是，1000個Hadoop節點通過50節點Kafka集群連接到500節點Spark集群進行處理。
只需列出我經常看到的環境類型，就可以快速了解這些多租戶大數據集群中可能出現的問題。例如：
超額訂閱群集 - 運行的應用程序或作業太多，資源不足
容器尺寸不合適 - 太大或太小
佇列管理不佳 - 佇列的大小不合適
資源佔用用戶或應用程序 - 集群中的壞蘋果
那麼你如何解決這些問題呢？
測量和分析
要了解上述哪些問題困擾您的群集，您必須首先了解幕後發生的事情。現代數據集群擁有許多運營團隊需要不斷關注的寶貴資源。這些包括內存，CPU和NameNode。
監控這些資源時，請確保在任何給定時間測量可用總量和消耗量。
接下來，按用戶，應用程序，部門和項目細分這些資源圖表，以真正了解誰對總使用量貢獻了多少。這種分析探索有助於快速揭示：
如果有任何一個租戶（用戶，應用程序，部門或項目）導致群集的大部分使用，那麼可能需要進一步調查以確定該租戶是否正在使用或濫用資源
哪些資源不斷受到超額訂閱的威脅
如果您需要擴展大數據集群或調整應用程序和系統以獲得更多成果
使應用程序成為更好的多租戶公民
群集和應用程序級別的配置設置決定了每個應用程序獲得的系統資源數量。例如，如果我們在主級別有一組8GB容器，那麼每個應用程序將獲得8GB容器（如果他們需要或不需要）。現在假設您的大多數應用程序只需要4GB容器。那麼當你的系統真正運行兩倍的應用程序時，你的系統會顯示它的最大容量。
除了低效的內存大小調整之外，由於其他錯誤的配置設置（CPU，容器數量，堆積大小等）低效的代碼和糟糕的數據佈局，大數據應用程序可能對多租戶公民不利。
因此，重要的是測量和理解系統上每個應用程序的每個資源佔用因素，並確保它們實際上正在使用而不是濫用資源。
定義佇列和優先級
您的大數據集群必須內置資源管理工具，例如YARN或Kubernetes。這些工具允許您將群集劃分為佇列。如果您希望將生產工作負載與實驗分開，或者將Spark與HBase分離，或將高優先級用戶與低優先級用戶分開，則此功能可以正常工作。訣竅是讓這些佇列的級別正確。
這是衡量和分析技術有用的地方。您應該分析用戶，部門或您認為合適的任何其他租戶對系統資源的使用情況，以確定他們通常要求的最小值，最大值，平均值。這將至少為您的佇列獲得一些常識水平。
但是，可能需要動態調整佇列級別以獲得最佳結果。例如，任務關鍵型應用程序如果每天處理的數據量比另一個要多5倍，則可能需要更多資源。因此，在分配這些水平時，具有季節感也很重要。群集使用的熱圖將使您能夠更準確地了解這些分配。
主動查找並修復流氓用戶或應用
即使您按照上述步驟操作，您的群集也會不時地遇到惡意使用。惡意使用被定義為應用程序或用戶在群集上的不良行為，例如從關鍵任務應用程序中佔用資源，佔用更多的CPU或內存而不是及時執行，具有非常長的空閒外殼。
在多租戶環境中，此類行為會影響所有用戶，並最終降低整個平台的可靠性。
因此，設置可接受行為的邊界對於保持大數據集群的運行非常重要。例如：
應用程序執行的時間限制
每個應用程序或用戶的CPU，內存，容器限制
應在分析一個月內的群集模式後設置這些邊界的閾值，以幫助確定平均值或接受值。對於一周中的不同日期，這些值也可能不同。另外，想想當這些邊界被破壞時會發生什麼。用戶和管理員應該收到警報嗎？這些流氓應用程序是應該被殺死還是移動到較低優先級的佇列？
只有通過思考這些選項，多租戶大數據集群才能很好地協同工作。
轉貼自： ITProPortal
若喜歡本文，請關注我們的臉書：Big Data In Finance
留下你的回應
以訪客張貼回應