究竟一個SAN的哪些部分應該設計成共享式的、又有多少部分應該設計成交換式的，這個問題必須視具體情況而定。在這一問題上，不應該將所存儲的數據量作為決定組建何種類型的SAN網絡的主要因素。相反，應該從數據的重要程度、網絡的距離要求、存儲設備的管理需求、數據的可用性和災難恢復的需求以及管理和應付配置改變的能力方面來考慮。
首先，應考慮企業內部如何進行重要數據的訪問。例如，對于通過并行的SCSI接口連接的存儲設備，服務器是控制中心。當服務器發生問題時，可能需要30到90秒才能夠正常復位。對于提供電子商務服務的公司，這段時間足以帶來致命的打擊，因此不能采用共享介質的SAN。因為這種網絡不能夠消除復位時間，而且由于令牌環還要進行一個環初始化過程(Loop Initialization Process)，這將導致所有設備的復位。
假如對數據的訪問具有相互競爭的需求，那交換式的結構體系則正好符合要求。假如對于存儲有距離要求(如跨越建筑物或是跨越園區內的多幢建筑物)，則SCSI可能就不是一種合適的選擇，因為SCSI的傳輸有70米的距離限制，即使使用了SCSI集線器或者中繼器也沒有用處。假如想要監視位于多個建筑物中的設備的狀態，光纖通道的SAN比較適合，因為它本身就能夠提供管理特性。使用位于環上的JBOD設備的部門，可以直接連接到位于SAN網絡主干上的交換機上，交換式主干于是就與服務器以及位于環上的存儲陣列直接連接，創建了一個虛擬的數據中心，為網絡管理員提供管理數據和信息。
最后，從災難恢復的角度來看，交換式的結構也是一個正確的選擇。在10公里或更遠距離以外創建一個冗余(備份)的數據中心，需要非常高的帶寬來進行數據同步，這一要求目前只有交換的方式能夠提供。
SAN的ASP
對于不同專業的從業人員，ASP有著不同的含義。但是當它和支持Web功能的ERP以及電子商務應用發生聯系時，ASP只能是可用性、靈活性和性能(Availability、Scalability、Performance)的代名詞。在這種解釋之下的ASP帶來了很多技術難題，那就是要求向用戶提供跨越網絡的可以持續穩定訪問的應用系統。
網絡上這種開放的服務刺激了用戶數量和數據的傳輸量，同時在應用上也產生了許多不可預知的問題。那些大型的ERP和電子商務系統遍布全球，為了提高性能，對這種應用的訪問需要強有力的數據緩存。沿用以前的系統(如大型主機)來裝載新的應用是一個極端，而選擇基于PC的低端服務器運行應用則是另外一個極端。相比之下，SAN是最佳的選擇，它能夠減輕所有這些問題。
SAN和集群
SAN可以被用作所有存儲資源的高級網絡主干，其中包括硬盤、磁帶、光纖通道的硬盤和遙控設備，它們在網絡上的所有服務器節點之間共享。支持SAN功能的集群使用了集群技術，也就是兩臺或多臺互相之間知道彼此配置和所提供的服務/應用的計算機系統完全協同工作在SAN拓撲環境中。一個真正意義上的SAN網絡早已超越了任意連通性、任意服務器到任意存儲系統的連通的觀念。事實上，通過將所有存儲系統從一個高速的網絡主干上隔離出來，或是通過在數據、存儲管理和使用這些數據的應用之間引入邏輯層/物理層，這種好處是相當巨大的。
為了實現無縫的存儲管理，SAN結構本來應該在所有存儲資源(如磁盤陣列、備份設備、邏輯卷的管理、文件系統管理和備份管理)以及所有需要這些資源的應用系統基礎之上，引進一個軟件層。那些運行在CPU數目滿足需求的服務器上的應用服務(如應用服務器、數據庫管理系統、中間件、HTTP服務器)能夠提供負載均衡和故障切換功能，而不需要專門的存儲設備。
這些應用服務并不知道數據存儲方面的有關信息，比如數據實際上究竟存放在什么地方、數據是否已經了鏡像和分布式處理等。所有基于網絡的RAID、分布式I/O、數據冗余、配置冗余、硬盤組、邏輯卷、動態的多個路徑、分層存儲、在線的高速備份等有關的問題都由存儲管理系統來處理。一個正確的SAN是一個能夠提供高可用性、增強的靈活性和改良的性能的基礎構架。
SAN能夠提供一個理想的拓撲結構來實現集群系統，因而其中一個系統的故障并不意味著所提供的服務會發生任何中斷。參與這一集群的其他一個或多個生還的結點將自動處理由故障結點所提供的應用或服務。支持SAN的集群的一個優點就是在集群環境中發生故障時恢復速度快。由于數據是持續可用的，問題僅僅是由備用或協同工作的應用來訪問原先由故障結點來訪問的數據。在能夠容忍的災難發生之后，SAN能夠通過光纖通道從10公里以外提供數據。
挑戰ERP和電子商務
在可用性、靈活性和性能要求很高的大型的、支持Web功能的ERP和電子商務環境中，SAN和支持SAN的集群解決了一些主要的技術問題，如更為靈活的備份手段、更快的恢復、正常運行時間更長。
從更高層次來看，現在具有三層或更多層結構的ERP和電子商務體系都向著一個方向發展，同時Baan公司、Oracle公司、PeopleSoft公司和SAP公司等不同廠商的系統之間還存在差別。現今所有ERP和電子商務應用都是支持Web功能的構件，就象OLAP構件、應用構件、數據庫構件一樣，在邏輯上是互相獨立的。
在應用結構適合SAN以后，最嚴重的問題便是這些模塊化的應用所訪問的大部分數據都集中在一個或很少幾個數據庫中(數據相當集中)。在這種情況下，一般可以對數據進行復制，以支持數據倉庫或是其他負載分解方式。由于這些應用支持Web功能，使消費者能夠對全球范圍的用戶分發他們的操作執行動作，這就使大量協同用戶同時訪問這些ERP和電子商務應用成為可能。
而市場的這一趨向又帶來了系統的可伸縮性問題。由于這些用戶遍布世界各地，所提供的服務就要求不能因為時間原因而中斷。這一趨勢同樣帶來了可用性問題。隨著用戶以顯著的速度增加，所收集和分發的數據的總量也以幾何級數的速度快速增長。隨之而來的便是要求對通過ERP和電子商務系統所收集到的數據(數據已經復制到了數據倉庫)進行分析、加以分類，并通過現存的和新啟用的應用進行擴充，于是這又帶來了與性能和速度有關的問題。所有這些因素更加明確地向結構體系提出了要求，要能夠解決可用性、靈活性和性能問題。
可用性(Availability)
可用性是持續正常運行時間的一個衡量指標。當然，目標是100%的正常運行時間，這表明ERP和電子商務應用服務沒有停工時間。通過對基礎構造的所有構件部分都建立冗余(即使這一冗余是明顯多余的，這是完全有可能達到的。
為所有冗余部件建立冗余備份的觀念能夠應用到SAN中的所有硬件和軟件中，如處理器、應用服務器、中間件、DBMS等。如今，為了實現高可用性和容錯，在ERP和電子商務應用環境中集群扮演了統治地位的角色。基于共享(如Oracle公司的產品)或非共享(如Sybase公司的產品)結構將兩臺或多臺服務器組成集群協同工作，是目前常用的方式。
在這兩種結構中，在系統和它們的存儲單元之間都有著必須的大量冗余的互連，這一問題直到SAN出現才解決。隨著SAN和基于SAN的集群的推出，由于在存儲系統和服務器之間引入了一個邏輯/物理層，因而消除了這種連接要求。SAN中的每一臺參與集群工作的服務器都能夠訪問SAN中的存儲空間中的每一個字節，因而消除了系統和它們的存儲系統之間的所有的互連需求。
沈陽數據恢復 
