本發(fā)明涉及地震勘探領域，特別涉及一種地震數(shù)據(jù)處理系統(tǒng)和方法。

背景技術：

在實際地震數(shù)據(jù)處理中，往往需要運行不同種類不同版本的地震數(shù)據(jù)處理軟件，其中每個地震數(shù)據(jù)處理軟件的運行又分別依賴于與各自兼容的操作系統(tǒng)和運行所需要的其他環(huán)境條件。

然而，在實際操作中往往不同的服務器運行不同的操作系統(tǒng)，從而使得軟件在運行有其兼容的操作系統(tǒng)的服務器上可以運行，但是在運行其不兼容的操作系統(tǒng)的服務器上無法運行，這樣勢必會導致軟件在某些服務器上無法直接運行，造成了使用不便和資源浪費。

為了解決上述問題，目前通常是采用虛擬機技術，即，通過生成新的虛擬鏡像，在這個獨立虛擬系統(tǒng)里面安裝軟件、運行軟件、以及保存運行所得的數(shù)據(jù)。然而，虛擬機技術所虛擬出的系統(tǒng)是整個操作系統(tǒng)，對于輕量應用并不十分適用。

例如，在地震數(shù)據(jù)研究領域，多數(shù)的地震數(shù)據(jù)處理軟件屬輕量應用，對于這種應用僅需要一個完整可用的運行環(huán)境，而非整個操作系統(tǒng)，如果使用虛擬機技術必然造成資源的浪費。進一步的，由于虛擬機技術應用時所依賴的物理CPU、內(nèi)存和硬盤一般都是硬件級別的，其資源分配是固定的，一般無法進行資源流動，這樣勢必會造成資源的閑置和浪費；另外，虛擬機的部署、運行通常都需要較長的時間，部署過程耗時長。

針對目前通過虛擬機技術對地震數(shù)據(jù)進行處理所存在的占用資源多、部署耗時長、使用不方便的問題，目前尚未提出有效的解決方案。

技術實現(xiàn)要素：

本發(fā)明實施例提供了一種地震數(shù)據(jù)處理系統(tǒng)和方法，以實現(xiàn)軟硬件資源的分離，從而解決通過虛擬機技術進行地震數(shù)據(jù)處理所存在的占用資源多、部署耗時、使用不方便的技術問題。

本發(fā)明實施例提供了一種地震數(shù)據(jù)處理的系統(tǒng)，包括：軟件資源池，用于通過應用Docker容器化技術提供地震數(shù)據(jù)處理軟件和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境；硬件資源池，用于提供所述地震數(shù)據(jù)處理軟件運行所需要的硬件資源；操作系統(tǒng)層，用于為所述的軟件資源池提供應用Docker容器化技術所需要的操作系統(tǒng)；資源調(diào)度管理層，用于為所述的地震數(shù)據(jù)處理軟件分配運行所需的硬件資源。

在一個實施例中，所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境，包括以下至少之一：與所述地震數(shù)據(jù)處理軟件兼容的操作系統(tǒng)，所述地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包，和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置。

在一個實施例中，所述軟件資源池包括：鏡像模塊，用于將所述地震數(shù)據(jù)處理軟件和所述軟件運行所需要的環(huán)境資源打包生成地震數(shù)據(jù)處理軟件鏡像文件，并保存為鏡像文件，保存在軟件資源池中；實例化模塊，用于對所述鏡像文件進行實例化生成容器，其中，地震數(shù)據(jù)處理軟件運行在所述容器中。

在一個實施例中，所述硬件資源池包括多個服務器。

在一個實施例中，資源管理調(diào)度層包括：服務器狀態(tài)監(jiān)控模塊、服務器分配模塊和存儲模塊，其中：所述服務器狀態(tài)監(jiān)控模塊，用于監(jiān)測所述多個服務器中各個服務器的資源耗用情況；所述服務器分配模塊，用于根據(jù)所述多個服務器中各個服務器的資源耗用情況，通過算法分析為所述地震數(shù)據(jù)處理軟件鏡像文件分配服務器；所述存儲模塊，用于以時間戳的方式保存所述服務器的資源耗用情況和為所述地震數(shù)據(jù)處理軟件鏡像文件分配服務器的分配信息。

在一個實施例中，所述資源管理調(diào)度層還包括告警模塊，用于從所述服務器狀態(tài)監(jiān)控模塊獲取每個服務器的資源耗用情況，并根據(jù)所述多個服務器中各個服務器的資源耗用情況對所述多個服務器進行判斷，對判斷為負載超出預設負載閾值或出現(xiàn)故障的一個或多個服務器發(fā)出告警。

在一個實施例中，所述Docker容器化技術所需要的操作系統(tǒng)包括以下至少之一：RedHat系統(tǒng)、Ubuntu系統(tǒng)和Centos系統(tǒng)。

在一個實施例中，所述的服務器狀態(tài)監(jiān)控模塊，具體用于在所述多個服務器中的各個服務器上配置名為Agent的常駐進程，通過所述常駐進程獲取每個服務器上的資源耗用情況。

在一個實施例中，所述服務器分配模塊，用于根據(jù)所述服務器的資源耗用情況和所述地震數(shù)據(jù)處理軟件鏡像文件實例化所需要的硬件資源，通過大數(shù)據(jù)分析算法為所述地震數(shù)據(jù)處理軟件鏡像文件分配進行實例化所需要的服務器。

本發(fā)明還提供了一種地震數(shù)據(jù)處理的方法，包括：布置多個服務器以組成硬件資源池，并在所述多個服務器中各個服務器上配置常駐進程，其中，所述常駐進程用于獲取所述多個服務器中各個服務器的資源耗用情況；通過Docker容器化技術對待運行的地震數(shù)據(jù)處理軟配置所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境，并打包生成地震數(shù)據(jù)處理軟件鏡像文件，并將所述鏡像文件保存在軟件資源池；為所述鏡像文件分配硬件資源池中的服務器；根據(jù)所述服務器資源耗用情況和所述地震數(shù)據(jù)處理軟件鏡像文件實例化所需要的硬件資源，通過大數(shù)據(jù)分析算法分配服務器；在所述服務器上將所述的地震數(shù)據(jù)處理軟件鏡像文件進行實例化以生成容器，在所述容器中運行所述的地震數(shù)據(jù)處理軟件以對地震數(shù)據(jù)進行處理。

在一個實施例中，所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境包括以下至少之一：與所述地震數(shù)據(jù)處理軟件兼容的操作系統(tǒng)，所述地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置。

在一個實施例中，所述通過大數(shù)據(jù)分析算法確定分配服務器，包括：通過運行服務器健康狀態(tài)公式，得到所述多個服務器中各個服務器的運行健康度；根據(jù)所述服多個服務器中各個務器的運行健康度，確定符合要求可分配的服務器。

在一個實施例中，所述服務器健康狀態(tài)公式為：

H_i＝(X₁*F₁+X₂*F₂+X₃*F₃...+X_t*F_t...+X_n*F_n)/n，

其中，H_i為第i個服務器的運行健康度，X_t為所述第i個服務器中的第t類運行資源的運行狀態(tài)轉(zhuǎn)換數(shù)值，F(xiàn)_t為所述第i個服務器中的第t類運行資源的占比，n為所述第i個服務器中的運行資源種類數(shù)，t為從1到n間的任意整數(shù)。

在上述實施例中：應用Docker容器化技術，通過軟件資源池，配合硬件資源池、操作系統(tǒng)層將待運行的地震數(shù)據(jù)處理軟件和其運行所需要的環(huán)境資源打包生成鏡像文件并保存在軟件資源池，實現(xiàn)了軟硬件資源的分離；由于采用了Docker容器化技術，相比于現(xiàn)有的虛擬機技術，只將軟件和軟件運行的環(huán)境打包生成鏡像保存，不需要虛擬整個系統(tǒng)，工作運行時占用的資源減少，運行的速度得到提高，部署所需時間更短。通過上述系統(tǒng)和方法解決了現(xiàn)有的虛擬機技術使用時占用資源多、部署耗時、使用不方便，不適用于地震數(shù)據(jù)處理軟件的技術問題。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，并不構(gòu)成對本發(fā)明的限定。在附圖中：

圖1是本發(fā)明實施例的地震數(shù)據(jù)處理系統(tǒng)的結(jié)構(gòu)示意圖；

圖2是本發(fā)明實施例的地震數(shù)據(jù)處理系統(tǒng)中的資源調(diào)度管理層的結(jié)構(gòu)示意圖；

圖3是本發(fā)明實施例中具有告警功能的地震數(shù)據(jù)處理系統(tǒng)的資源調(diào)度管理層的結(jié)構(gòu)示意圖；

圖4是本發(fā)明實施例的地震數(shù)據(jù)處理方法的處理流程圖；

圖5是本發(fā)明實施例的通過加入新服務器更新擴展硬件資源的處理流程圖；

圖6是本發(fā)明實施例的通過部署新軟件更新擴展軟件資源的處理流程圖。

具體實施方式

為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，下面結(jié)合實施方式和附圖，對本發(fā)明做進一步詳細說明。在此，本發(fā)明的示意性實施方式及其說明用于解釋本發(fā)明，但并不作為對本發(fā)明的限定。

本發(fā)明實施例提供了一種地震數(shù)據(jù)處理系統(tǒng)，以下所使用的術語“模塊”可以是實現(xiàn)預定功能的軟件和/或硬件的組合。圖1是本發(fā)明實施例的地震數(shù)據(jù)處理系統(tǒng)的結(jié)構(gòu)示意圖，如圖1所示，可以包括：軟件資源池101、硬件資源池102、操作系統(tǒng)層103和資源調(diào)度管理層104，下面對該結(jié)構(gòu)進行說明。

軟件資源池101，用于通過應用Docker容器化技術提供地震數(shù)據(jù)處理軟件和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境；

硬件資源池102，用于提供所述地震數(shù)據(jù)處理軟件運行所需要的硬件資源；

操作系統(tǒng)層103，用于為所述的軟件資源池提供應用Docker容器化技術所需要的操作系統(tǒng)；

資源調(diào)度管理層104，用于為所述的地震數(shù)據(jù)處理軟件分配運行所需要的硬件資源。

在上述實施例中，主要是考慮到現(xiàn)有的采用虛擬機技術進行地震數(shù)據(jù)處理時候，由于虛擬機技術自身的局限和問題，往往會存在占用資源多、部署耗時、使用不方便等問題，為此，在本例中提出了一種基于Docker容器化技術的地震數(shù)據(jù)處理方法，Docker是一個應用容器引擎，Docker容器化技術可以包括：鏡像容器管理、資源配額與度量、進程隔離與安全和硬件兼容，該技術允許開發(fā)者將應用軟件以及該軟件運行所需的環(huán)境資源打包到一個可移植的容器中，然后發(fā)布到某個符合要求可分配的服務器上，實現(xiàn)該軟件的虛擬化運行。

在實際的地震數(shù)據(jù)處理中，相較于虛擬機技術，使用Docker容器化技術的優(yōu)勢主要在于，多數(shù)用于地震數(shù)據(jù)處理的軟件大多屬輕量應用，僅需要一個完整可用的運行環(huán)境，而非整個操作系統(tǒng)，虛擬機技術虛擬出來的整個系統(tǒng)，而且要求軟件運行所需的資源環(huán)境都是固定的不可以流動的，從而容易造成資源的浪費，然而，Docker容器化技術基于自身的技術特點只需要將應用軟件和軟件運行所需的環(huán)境資源打包到一個可移植的容器中，就實現(xiàn)軟硬件分離，運行時按需要將容器分配到某個符合要求的服務器上，實現(xiàn)軟件的虛擬化運行即可，這樣就達到了占用資源少、部署簡單便捷的效果。進一步的，Docker容器技術可以解決虛擬機技術所解決的兼容性問題。在部署應用軟件時，僅需配置一次軟件運行所需的環(huán)境，并將所需要的環(huán)境和軟件一起保存為鏡像，就可以在后期運行不同操作系統(tǒng)的服務器上以容器的方式運行該軟件，使用起來較為方便，且運行速度快。在軟件運行的時候，一個容器就是一個單獨的運行環(huán)境，與其他容器完全獨立，互不干擾，從而可以解決資源爭用的問題，同時，通過資源調(diào)度管理層的分配和管理，保證了資源可以按照需要進行合理和有效的分配。

在上述實施例中，為了保證地震軟件的正常運行，提供的所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境，可以包括以下至少之一：與所述地震數(shù)據(jù)處理軟件兼容的操作系統(tǒng)，所述地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包，和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置。然而，值得注意的是，上述所列舉的運行所需要的環(huán)境僅是一種示意性描述，是為了更好地說明本發(fā)明，然而，在實際執(zhí)行的過程中，還可以包括軟件運行所需的其它環(huán)境，本申請對此不作限定。

上述實施例中，與地震數(shù)據(jù)處理軟件相兼容的操作系統(tǒng)可以是在地震數(shù)據(jù)處理中能運行Docker容器的操作系統(tǒng)，這些系統(tǒng)可以是由操作系統(tǒng)層103提供的不同版本不同類型的操作系統(tǒng)，例如，可以包括：RedHat系統(tǒng)、Centos系統(tǒng)和Ubuntu系統(tǒng)。其中，RedHat系統(tǒng)是用Linux核心構(gòu)架的一種操作系統(tǒng)，由于它具備相對較好的圖形界面，無論是安裝、配置還是使用都十分方便，而且運行穩(wěn)定。Centos系統(tǒng)和RedHat系統(tǒng)都是基于同樣的源代碼編譯出來的。然而，值得注意的是，上述所列舉的系統(tǒng)僅是一種示意性描述，是為了更好地說明本發(fā)明，然而，在實際執(zhí)行的過程中，還可以包括其它類型的系統(tǒng)，可以根據(jù)實際需要選取，本申請對此不作限定。

上述實施例中，地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包可以是本地服務器中有的數(shù)據(jù)包和本地服務器中沒有的數(shù)據(jù)包，其中，本地服務器中沒有的數(shù)據(jù)包可以從公有倉庫獲得，其中，公有倉庫可以是互聯(lián)網(wǎng)上的公有資源庫。

上述實施例中，地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置可以是手動設置或自動生成的軟件運行所需的環(huán)境參數(shù)配置。

考慮到在本發(fā)明實施例需要將軟件和硬件資源是分隔離來，因此地震數(shù)據(jù)處理軟件可以通過鏡像和實例化的方式生成和存儲，為此，上述軟件資源池101可以包括：鏡像模塊，用于將地震數(shù)據(jù)處理軟件和該軟件運行所需的資源環(huán)境打包生成地震數(shù)據(jù)處理軟件鏡像文件，并保存在軟件資源池中；實例化模塊，用于對所述的鏡像文件進行實例化以生成容器，其中，地震數(shù)據(jù)處理軟件運行在所述的容器中。即，將地震數(shù)據(jù)處理軟件和地震數(shù)據(jù)處理軟件運行所需要的環(huán)境打包生成鏡像文件，并在需要運行軟件的時候，將鏡像文件中的軟件進行實例化，以便在容器中運行該軟件對地震數(shù)據(jù)進行處理。

上述實施例：應用Docker容器化技術，通過軟件資源池101配合硬件資源池102、操作系統(tǒng)層103將待運行的地震數(shù)據(jù)處理軟件和其運行所需要的環(huán)境資源打包生成鏡像文件并保存在軟件資源池101中，從而實現(xiàn)了軟硬件資源的分離。相比于現(xiàn)有的虛擬機技術，本實施例采用Docker容器化技術只需要將待運行軟件和軟件運行所需要的環(huán)境打包生成鏡像保存，而不需要重建整個系統(tǒng)，使得地震數(shù)據(jù)處理所需占用的資源減少，且有效提高了地震數(shù)據(jù)處理軟件的運行速度。

具體實施時，為了使得多個軟件可以同時運行，以提高數(shù)據(jù)處理的效率，在本實施例中，上述硬件資源池102可以包括多個服務器，從而達到對多個軟件的并行處理，進一步的，多個服務器的處理能力也可以是不同的，在實際執(zhí)行的時候，就可以根據(jù)每個軟件所需的硬件資源條件選擇合適的服務器運行，當然也可以根據(jù)服務器處理能力的不同，在不同的服務器分配不同數(shù)量的待處理數(shù)據(jù)或者待運行軟件。

考慮到系統(tǒng)中設置了多個服務器，在執(zhí)行的過程中，就會涉及到服務器的分配問題，為了使得服務器的分配更為合理，以提高資源的利用率，在一個實施例中，如圖2所示，資源調(diào)度管理層104可以包括：服務器狀態(tài)監(jiān)控模塊201、服務器分配模塊202和存儲模塊203，其中：

服務器狀態(tài)監(jiān)控模塊201，可以用于監(jiān)測多個服務器中各個服務器的資源耗用情況；

服務器分配模塊202，可以用于根據(jù)多個服務器中各服務器的資源耗用情況和待運行地震數(shù)據(jù)處理軟件鏡像文件實例化所需要的硬件資源，通過算法分析為地震數(shù)據(jù)處理軟件的鏡像文件分配符合要求的服務器；

存儲模塊203，可以用于以時間戳的方式保存服務器的資源耗用情況和為地震數(shù)據(jù)處理軟件鏡像文件分配服務器的分配信息。

即，通過各個服務器當前的耗用情況進行服務器的分配，例如：可以將當前資源耗用最小的服務器分配給當前待執(zhí)行的地震數(shù)據(jù)處理軟件，也可以將當前所剩資源大于當前待執(zhí)行的地震數(shù)據(jù)處理軟件中所剩資源最小的服務器分配給當前待執(zhí)行的地震數(shù)據(jù)處理軟件，具體地分配策略可以根據(jù)實際需要選取，本申請對此不作限定。

考慮到在具體實施過程中為了準確制定分配策略，需要時刻了解每個服務器的資源耗用情況，本實施例中的服務器狀態(tài)監(jiān)控模塊201可以在每個服務器上都配置一個名為Agent的常駐進程，通過該常駐進程就可以實時獲取各個服務器上資源的耗用情況。

上述服務器分配模塊202具體地，可以通過大數(shù)據(jù)分析算法確定分配策略，然后，按照分配策略為地震數(shù)據(jù)處理軟件鏡像文件分配符合要求并可以運行的服務器。其中，上述的通過大數(shù)據(jù)分析算法確定分配策略可以包括：通過運行服務器健康狀態(tài)公式，得到所述多個服務器中各個服務器的運行健康度；根據(jù)所述多個服務器中的各個服務器的運行健康度，確定符合要求可分配的服務器。

考慮到在具體實施過程中存儲模塊203主要是存儲的實時的服務器資源耗用情況和實時的服務器分配信息，所存儲的主要信息大都與時間有密切的聯(lián)系，為了提高存儲或讀取的效率，存儲模塊203可以采用NoSQL(Not Only Structured Query Language，非關系型)數(shù)據(jù)庫，并以時間戳的方式保存服務器各個時間段的資源耗情況、各鏡像實例化需要的硬件資源、分配給每個容器的資源情況、鏡像更新與容器啟動關閉等事件記錄。其中，時間戳方式是在所需記錄存儲的信息前冠以時間戳，以體現(xiàn)所記錄存儲的信息在每個時間段里的狀態(tài)，方便后期分析使用。上述非關系型數(shù)據(jù)庫存儲數(shù)據(jù)的方式為列式存儲，通過這種存儲方式可以高效地存儲或讀取以時間戳方式保存的信息。

在一個實施例中，為了及時發(fā)現(xiàn)并對有問題或故障的服務器進行告警，如圖3所示，資源管理調(diào)度層104還可以包括分析判斷模塊204和告警模塊205，其中，分析判斷模塊204用于從服務器狀態(tài)監(jiān)控模塊201獲取服務器的資源耗用情況，并對獲取的資源耗用情況進行分析，并判斷服務器是否過載或故障；告警模塊205用于對被判斷為負載超出預設負載閾值或出現(xiàn)故障的一個或多個服務器發(fā)出告警。在本實施例中，通過在資源調(diào)度管理層中設置了分析判斷模塊204和告警模塊205，從而可以對負載超出預設負載閾值或出現(xiàn)故障的服務器發(fā)出告警，以保證整個系統(tǒng)運行的穩(wěn)定和安全。

基于同一發(fā)明構(gòu)思，本發(fā)明實施例中還提供了一種地震數(shù)據(jù)處理方法，由于地震數(shù)據(jù)處理方法解決問題的原理與地震數(shù)據(jù)處理系統(tǒng)相似，因此涉及到一些相同的技術和原理在此不再贅述。如圖4所示，該地震數(shù)據(jù)處理方法可以包括以下步驟：

步驟401：布置多個服務器以組成硬件資源池，并在所述多個服務器上配置常駐進程，其中，所述常駐進程用于獲取所述多個服務器中各個服務器的資源耗用情況；

步驟402：通過Docker容器化技術將地震數(shù)據(jù)處理軟件和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境打包生成地震數(shù)據(jù)處理軟件鏡像文件，并將所述鏡像文件保存在軟件資源池；

步驟403：為所述鏡像文件分配硬件資源池中的服務器；

步驟404：在分配的服務器上將所述鏡像文件進行實例化以生成容器，在所述容器中運行所述地震數(shù)據(jù)處理軟件以對地震數(shù)據(jù)進行處理。

在上述實施例中，為了保證地震軟件的正常運行，提供的所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境，可以包括以下至少之一：與所述地震數(shù)據(jù)處理軟件兼容的操作系統(tǒng)，所述地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包，和所述地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置。然而，值得注意的是，上述所列舉的運行所需要的環(huán)境僅是一種示意性描述，是為了更好地說明本發(fā)明，然而，在實際執(zhí)行的過程中，還可以包括軟件運行所需的其它環(huán)境，本申請對此不作限定。

上述實施例中，與地震數(shù)據(jù)處理軟件相兼容的操作系統(tǒng)可以是在地震數(shù)據(jù)處理中能運行Docker容器的操作系統(tǒng)，這些系統(tǒng)可以是由操作系統(tǒng)層103提供的不同版本不同類型的操作系統(tǒng)，例如，可以包括：RedHat系統(tǒng)、Centos系統(tǒng)和Ubuntu系統(tǒng)。然而，值得注意的是，上述所列舉的系統(tǒng)僅是一種示意性描述，是為了更好地說明本發(fā)明，然而，在實際執(zhí)行的過程中，還可以包括其它類型的系統(tǒng)，可以根據(jù)實際需要選取，本申請對此不作限定。

上述實施例中，地震數(shù)據(jù)處理軟件運行所需要的數(shù)據(jù)包可以是本地服務器中有的數(shù)據(jù)包和本地服務器中沒有的數(shù)據(jù)包，其中，本地服務器中沒有的數(shù)據(jù)包可以從公有倉庫獲得，其中，公有倉庫可以是互聯(lián)網(wǎng)上的公有資源庫。

上述實施例中，地震數(shù)據(jù)處理軟件運行所需要的環(huán)境參數(shù)配置可以是手動設置或自動生成的軟件運行所需的環(huán)境參數(shù)配置。

具體實施時，為了合理、有效地分配資源，本發(fā)明實施例通過大數(shù)據(jù)分析算法確定分配策略，可以包括：通過運行服務器健康狀態(tài)公式，得到服務器運行該容器的健康度；根據(jù)服務器運行該容器的健康度，確定符合要求可分配的服務器。

上述施例中所使用服務器健康狀態(tài)公式為：

H_i＝(X₁*F₁+X₂*F₂+X₃*F₃...+X_t*F_t...+X_n*F_n)/n，

其中，H_i為第i個服務器的運行健康度，X_t為所述第i個服務器中的第t類運行資源的運行狀態(tài)轉(zhuǎn)換數(shù)值，F(xiàn)_t為所述第i個服務器中的第t類運行資源的占比，n為所述第i個服務器中的運行資源種類數(shù)，t為從1到n間的任意整數(shù)。

考慮到具體使用該公式時，上述的服務器中的運行資源主要可以是服務器的性能資源，例如可以包括：服務器的CPU、服務器的硬盤資源和服務器的網(wǎng)絡資源等。不同實施情況下，可以根據(jù)具體情況調(diào)整其中第t類資源在該服務器健康度中的占比值F_t。

在實際使用的過程中，考慮到軟件類型的增多，或者是待處理地震數(shù)據(jù)的增多，可以設置對地震數(shù)據(jù)處理系統(tǒng)的擴展，這種擴展可以是硬件層面的擴展，也可以是軟件層面的擴展，下面分別對這兩種擴展進行說明：

1)通過加入新服務器對硬件資源進行更新擴展，如圖5所示，可以包括：對新購置的服務器安裝兼容的操作系統(tǒng)，并通過資源管理調(diào)度層在新購置的服務器上部署Docker組件及服務器狀態(tài)監(jiān)控模塊的Agent監(jiān)控進程，從而將該新購置的服務器加入到硬件資源池中；然后，對新加入硬件資源池的服務器的運行狀況進行檢查：對于經(jīng)檢查符合分配條件的服務器，將待運行地震數(shù)據(jù)處理軟件的鏡像文件分配到該服務器上進行實例化以生成容器，并監(jiān)控其運行情況；對于不符合分配條件的服務器，判斷其是否故障，如果無故障，則重新對該服務器的運行狀況進行檢查，如果有故障，則將新加入的服務器從硬件資源池中刪除，并對該服務器進行修復，待故障被修復后，再重新將該服務器加入到硬件資源池中。

2)通過新部署軟件對軟件資源進行更新擴展，如圖6所示，可以包括：根據(jù)新部署的軟件對操作系統(tǒng)的要求，從操作系統(tǒng)層中找到與該新部署軟件兼容的操作系統(tǒng)；然后，再根據(jù)新部署軟件的運行所需要的其他環(huán)境資源，加入運行所需要的其他環(huán)境條件。基于分配的操作系統(tǒng)和運行所需的其他環(huán)境資源，檢測軟件的運行效果是否達到預設要求，如果未達到，則繼續(xù)補充該軟件運行所需要的環(huán)境資源直到軟件的運行效果可以達到預設要求，如果可以達到，則將當前的運行環(huán)境和該軟件打包生成鏡像，同時將該鏡像上傳并保存在軟件資源池中。

上述實施例：應用Docker容器化技術，通過軟件資源池，配合硬件資源池、操作系統(tǒng)層將待運行的地震數(shù)據(jù)處理軟件和其運行所需要的環(huán)境資源打包生成鏡像文件并保存在軟件資源池，實現(xiàn)了軟硬件資源的分離；通過資源調(diào)度管理層，根據(jù)所述多個服務器中各個服務器上的資源耗用情況和所要運行的地震數(shù)據(jù)處理軟件鏡像文件實例化運行所需要的硬件資源，將地震數(shù)據(jù)處理軟件的鏡像文件分配到符合要求可運行的服務器上，進行實例化以生成容器，實現(xiàn)合理、有效地利用資源；由于采用了Docker容器化技術，相比于現(xiàn)有的虛擬機技術，本發(fā)明實施例只將待運行軟件和軟件運行所需的環(huán)境打包生成鏡像并保存，不需要虛擬整個系統(tǒng)，工作時占用的資源減少，運行的速度得到提高；另外還通過在存儲模塊采用NoSQL數(shù)據(jù)庫和時間戳保存方式提高了相關含時間信息的數(shù)據(jù)存儲或讀取的效率。通過上述系統(tǒng)或方法解決了現(xiàn)有的虛擬機技術使用時占用資源多、部署耗時、使用不方便，不適用于地震數(shù)據(jù)處理軟件的技術問題，達到了在實現(xiàn)軟硬件資源分離的同時，占用資源小，運行速度快，運行環(huán)境獨立互不干擾，有效合理利用資源的技術效果。

顯然，本領域的技術人員應該明白，上述的本發(fā)明實施例的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明實施例不限制于任何特定的硬件和軟件結(jié)合。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明實施例可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。