災害復原系統
YODOBASHI CAMERA公司

災害復原：確保企業永續營運的重要關鍵

在過去幾年，對於災害復原的需求成長非常的快速。在這個發展趨勢背後有二項非常關鍵的影響因素，其中之一就是：無論企業或是個人日常生活，對於資訊科技的依賴越來越重。現在，如過沒有資訊系統，可能企業的日常營運就很難進行。另一個影響因素是，大家都認知到災害的風險及意外，會對企業系統帶來大規模的危害。

在這些已知的災害風險背後，有一個非常重要的原因，是就是發生在2001年九月美國所遭遇的恐怖攻擊事件。但除了這類巨大的災害之外，日常中也是會面臨許多災害的風險，像是火災及地震，尤其是位於火山地帶的日本，因為地震所引發的災害，就是一個永遠潛在的風險。

災害復原系統針對這類事件已經做好萬全準備。首先，他們在別處設置了復原設備，當原有端當機時，還可以持續的處理資料並提供服務，確保企業的永續營運。建構一套災害復原系統是非常重要的，而且，和建構常用的系統相比較，建構一套復原單位，在設備、功能上的投資也和原有端是一樣的重要。

此外，原有端和復原端之間也需要同步資料連結的機制，如此，無論在任何時間，都可以從復原端持續的提供服務。但是仍舊有許多企業對於這類的投資抱持猶豫態度，甚或是對於復原機制能否如預期般的運作，讓作業進行無阻礙，依舊有所懷疑。

在2002年5月，一套系統所展現的能力消除了先前對於運作效能上所有猶豫與懷疑：Yodobashi Camera災害復原系統。

眾所週知在資訊科技投資有前瞻眼光的Yodobashi Camera公司，是日本三大用品供應商之一。在1995年，他是日本第一家率先採用SAP R3作為核心系統的供應商；在1999年，該公司佈建了針對所訂單與銷售相關資訊進行集中管理的Retail and Business-information Warehouse(BW)模組，而且從2001年4月開始建構一套災害復原系統來保護這些系統，並在2002年開始運作。

在考慮可行技術與成本之後，Yodobashi Camera開始尋找以IP為作業基礎的系統

“針對災難復原的議題我們已經思考了相當的時日。” Yodobashi Camera公司執行董事暨企業總部首長Kazunori Fujisawa如此表示。該公司在2002年一月十整體銷售總額已經突破四千億日圓，任何一個系統若因為災害因素而停擺幾天，都會導致數百萬日圓的損失。為了避免承擔這樣的風險，災害復原就成為該公司非常重要的管理議題。然而，甚至在幾年前，佈建一套災害復原系統，無論從技術或是成本的觀點來看，仍被視為是件單純且不實際的事。但是到了2000年，佈建一套災害復原系統卻已經是件實際可行的選擇。在這段時間，遠端間低成本的通訊服務，配合提供同步資料的技術能力與解決方案紛紛出籠。因此，我們決定，該是開始去尋找佈建一套災害復原系統的適當時機了。

系統的結構可以用以下的圖表來展現。復原端所在地與原始端之間有數百公里的距離，通常在建構一套災害復原系統的時候，ATM經常會被用來當做網點間的通訊之用。但是，Yodobashi Camera公司電腦部門董事暨總經理Kenji Hirota解釋，基於三項理由，所以，他們決定採用IP網路作為內部通訊開發基礎。”第一個原因是標準化的IP通訊協定，可以讓我們的作業更加便利；第二個原因是，和採用ATM的方式相比較，我們可以降低一半的通訊成本；第三個原因是，IP提供我們未來無限的發展的潛力。”廣域的IP網路剛開始時只是用來提供服務，但是，預期未來對於IP應用軟體的使用，將會有爆炸性的成長。
這套災害復原系統採用HP磁碟陣列xp512，這是目前產業內同類產品中功能最大的系統，搭配使用Brocade通訊系統公司的FC轉換器、CNT公司的UltraNet Edge Storage Router（作為SAN與IP通訊協定轉換之用），及Cisco公司的Layer 3轉換器，讓儲存於不同地點的資料，可以達到同步的目的。而所有的應用軟體都安置在HP的旗艦UNIX伺服主機—HP superdome上，這也是在原始端的核心系統，可以為企業帶來非常高的使用效能、擴充性與可用性。在這整個系統結構中，還有一套用來提供資料中心failover功能的ContinentalClusters與MC/ServiceGuard叢集中介軟體，及遠端資料複製解決方案Continuous Access xp。這些要素的組合建構成了一套完整的應用環境，讓企業在面臨災害發生而原始端無法正常作業的時候，所有的日常營運業務仍舊可以從復原端持續的運作。

確保系統結構的一致性，HP竭盡所能提供所需解決方案

HP著手進行系統開發的每一個步驟，從系統需求確認到作業流程設計、建置與測試。承續為Yodobashi Camera公司建置SAP R/3的一貫承諾，HP再度展現其備受好評不屈不撓的精神與專業技術。
這項建置專案共分成三個不同發展階段。第一階段係從2001年四月到八月，主要工作在進行需求確認與系統設計。從六月到九月的第二階段，則開始進行設備測試。從九月開始真正進行系統建構的第三階段，就已經開始連結數百公里遠的復原端與原始端上的SAP R/3營運系統，而整套災害復原系統則從2002年五月開始上線運作。

Yodobashi Camera公司的核心系統都建置在全球應用領域範圍最廣的SAP R/3系統上。在這類頂級系統中，也提供了一些建構在IIP網路上的災害復原系統範例，不過，這類系統是透過各種子系統間的連結來提供災害復原作業的保護，若是需要維持不同應用軟體間資料的一致性，就需要再提供一些具有failover的解決方案。但是，這些災害復原系統範例卻對整個專案的進行帶來非常大的挑戰。不過藉由Yodobashi Camera與HP二家公司之間緊密的合作，還是締造了這項令人咋舌的成功經驗。而且，在成功的背後，我們還發現了許多專案管理的特色。

首先，小心進行建置前測試，這可以確保災害復原系統的可靠程度。在第二階段的時候利用HP公司內的測試環境，針對實際的營運資料進行運作測試，以減少系統實際建置後的障礙風險。
對任何災害復原系統來說，作業流程設計都是非常重要的一環。另外每日的作業管理也需要清楚的定義，找出在災害事件中failover的功能該如何實施。就像我們在系統中所採用的企業永續支援解決方案（Business Continuity Support；BCS），HP從專案的一開始就投入了作業支援小組，從複雜的作業中設計出所需要解決方案。
在內部通訊設備選擇方面，HP也採用了其他廠商的產品。HP針對這些產品的選購提供了一次購足的服務，Fujisawa說，”和HP合作的優點之一，就是在他們所提的規劃中，所容納其他廠商的產品也都能夠完全支援專案所要求。” ，“無論是產品的選擇與功能規劃，都非常的合理。他們的技術專業為我們帶非常大的便利。”

建立未來的標準：無限的安心

若要建構一套災害復原系統，就必須改變系統基礎架構。因此，應用軟體能否繼續的有效運用，也就備受關注。但是在Yodobashi Camera的個案中，這些擔心都一掃而空了。需要的應用軟體無須改變，因為ContimentalClusters以MC/ServiceGuard的叢集功能為基礎，讓應用軟體在MC/ServiceGuard上可以如同以往一般繼續的運作。對於一些採用像是SAP R/3這類ERP套裝系統的公司來說，這帶來了極大的利益。在佈建災害復原系統時，Yodobashi Camerae公司以磁碟陣列作為其核心系統，大幅降低了磁碟設備的失誤。先前該公司已經採用其他廠商所提供的高階儲存設備，Hirota說，”我們有許多磁碟設備，但是這些設備每週都會定時的當機。”，然而，轉換到xp512設備後，每六個月才需要更換一次磁碟。磁碟設備基本上是種消耗品，但是磁碟的更換是不需要中斷服務的。因此，大幅減少磁碟更換的頻率是非常重要的，這不但可以增加系統的可靠性，更可減少更換作業所需要的時間與作業。"佈建這套災害復原系統之後，我們終於可以高枕無憂。"Fujisawa說， "對我們的營運來說，這類系統的功能是非常重要的。毫無疑問，我們走對了方向。"