6. Symantec Data Center Solutions
資料庫
中介軟體
應用程式
Symantec Data Center Solutions
NetBackup
資料保護
網路
Veritas Cluster Server 介紹
Storage Foundation
儲存虛擬化
儲存
伺服器
Server Management
伺服器生命週期
虛擬主機
6
7. 啟動 IT Service Management
Event Console
Help Desk
IT Ops Management
Console/ Framework
Symantec Data Center Foundation
容量的
管理及分配
設定的
管理
NetBackup
資料保護
資訊安全的
管理
可用性的
管理
Storage Foundation
儲存虛擬化
IT 服務的
持續性
Server Management
伺服器生命週期
Integration Platform
Federated Console
Business Analytics
Workflow
Single Sign-On
License Management
Common Agent Deploy
CMDB Integration
Directory Integration
Veritas Cluster Server 介紹
7
12. 建構 HA 及 DR 架構
Global Clustering
Local HA
APP 3
APP 2
APP 1
Synch
Replication
or Mirroring
Veritas Cluster Server 介紹
Wide-Area DR
(Stretch Cluster)
APP 4
SAP
Metropolitan HA
(Global Cluster)
SAP
APP 4
APP 3
APP 2
APP 1
Asynchronous
Replication
12
26. New in 6.0
透過 Virtual Business Services 建立你的私有雲
會計部門
人資部門
Billing VBS
AppHA
財務部門
Finance VBS
HR VBS
AppHA
AppHA
AppHA
VCS
AppHA
AppHA
VCS
AppHA
VCS
Veritas Operations Manager
CFS HA
Veritas Cluster Server 介紹
SF HA
26
27. New in 6.0
VBS – 在雲端管理複雜度
Billing
Service
Group
Service
Group
Web
Web server
Web
服務啟動
服務停止
高可用性
災難備援
VM
VM
Application
Service
Group
App
app
app
app
人員沒空?
IP
不同的密碼
Database
不同的工具
Service
Group
DB
IP
處理虛擬化
FS
整合的還原
VVR
Veritas Cluster Server 介紹
27
28. New in 6.0
VBS – 透過多層次雲端應用程式管理 SLAs
Billing
Service
Group
Veritas Operations Manager
Service
Group
Web
Web server
Web
Billing Virtual Business Service
VM
VM
App server
Web Server SG
Service
Group
App
app
app
app
Application Server SG
IP
Database
Service
Group
Database SG
DB
IP
FS
VVR
Veritas Cluster Server 介紹
28
29. New in 6.0
VBS – Orchestrate Starts
VBS
服務啟動
高可用性
VBS
服務停止
災難備援
Started
ON
Billing
Start Web Tier
Web
Start App Tier
App
Start DB Tier
Started
DB
VBS
Veritas Cluster Server 介紹
29
30. New in 6.0
VBS - Orchestrate Stops
VBS
服務啟動
高可用性
VBS
服務停止
災難備援
Stopped
ON
Stopped
Billing
Stop Web Tier
Web
Stop App Tier
App
Stop DB Tier
DB
VBS
Veritas Cluster Server 介紹
30
31. New in 6.0
VBS – Achieve Business Service High Availability
VBS
服務啟動
高可用性
AppHA
AppHA
AppHA
服務停止
災難備援
AppHA
Configurable
reaction
• Stop
• Restart
• Maintain
VBS
Event
高可用性的
自動化
獨立的問題
回應
VBS
可設定的回應方式
無全新的基礎架構
Veritas Cluster Server 介紹
31
32. New in 6.0
VBS - Ensure Business Continuity
STOP
BILLING VBS
VBS
BILLING DR VBS
VBS
START
AppHA
服務停止
高可用性
AppHA
服務啟動
災難備援
AppHA
AppHA
VCS KVM
VBS
VBS
簡化的 DR
整合架構
Single Node VCS
VCS
DR
VBS
企業服務層級
通知
VBS
實體/虛擬環境混搭
Replication
VCS
PRODUCTION SITE
Veritas Cluster Server 介紹
SF/HA
區域重新定義能力的
Active/Active DR
DR SITE
32
Symantec’s ability to work across this heterogeneous environment gives IT organizations a way to ensure the availability ofmulti-tiered applications, because Symantec will provide visibility and coordinated start and stop for all business servicecomponents—even if the Web server sits in a VMware virtual machine, the application server in KVM on Linux, and thedatabase on physical Big Iron.Using Symantec, HA can work across heterogeneous infrastructure, using the cross-platform layer to provide end-to-endHA information about an entire business service, comprising a multi-tier application and the heterogeneous infrastructurethat supports it. Infrastructure HA aligns with and extends the core concepts of virtualization itself, by poolinginformation resources even across heterogeneous infrastructure, and making them available on-demand for infrastructureHA, or management solutions to take appropriate action to maintain service continuity.Figure 1 shows a typical data-center server infrastructure, with one set of x86 servers hosting Windows and Linux virtualmachines, another set running applications and middleware directly, and a set of “big iron” proprietary hardware runningUNIX. A single Tier 1 application, “eCommerce”, crosses all three levels, with Web services running on x86 VMs,applications on physical x86 servers under a JBoss Enterprise Application Platform, and a database—shared with otherapplications—on a UNIX platform
Managing HA & DR for multi-tier applications can be challenging. You want the service to start and stop in a coordinated manner, and if a fault occurs in one component of the application stack, that component must restart elsewhere and other components – or tiers – of the stack might need to be restarted. Often, responsibility for different tiers of the application stack is spread among different people, so the different groups must coordinate with each other to get the entire service back online.The challenges are compounded when components of the stack run on different OS and virtualization platforms and are managed with different tools.
Virtual Business Service eliminates the complexity associated with managing such multi-tier applications. Configured through VOM, the user defines the dependencies between the components of the application stack. Once that’s done, the entire service can be started and stopped with a couple clicks of a mouse.This example shows a fairly typical 3-tier application stack, with database and app tiers running on physical servers, and the web tier running on virtualized servers.Now, let’s take a look at how VBS handles faults and fault propagation.
Also show the other boxes, but without a check box
Here is how Virtual Business Service automates the start ordering. In this case, we want the Database tier to be started first, followed by the Application tier and then, finally the Web tier should be started. Only then should we consider this multi-tier application to be online. Additionally, in this example, we have to start the VM before we can start the Web tier.All we need to do is to go to VOM, pull the corresponding Service Groups into a single Virtual Business Service and define the start-up order. Once we have defined the Virtual Business Service, the configuration information is pushed down to all the clusters. After this, whenever we need to start the Virtual Business Start, we can either start it through VOM or using CLI from any of the participating clusters as a single step operation. VBS will internally start the components in the required order. VOM need not be online for starting the VBS and all the communication between the clusters is internally handled by the Virtual Business Service component.
Now, let us turn to the interesting area of inter-cluster fault propagation. As we saw before, we have VCS handling the High Availability at the level of each tier and hence, the HA decisions will be independently made by VCS at the level of each cluster.Let us assume the node hosting the DB in the DB tier faulted. VCS will kick in and provide fast failover of the DB to the stand-by node. We have heard of several configurations where the middle tier component needs a restart to react to the failover of the underlying DB tier. To enable such use cases, Virtual Business Service will notify the middle tier about the fault and recovery that has occurred in the DB tier. The reaction of the middle tier to this event at the lower tier can be configured. The middle tier can choose to restart so as to update its in-core state to reflect the failover at the DB tier or it can choose to ignore the event.More policies can be made available – for instance, we can allow for custom scripts to be triggered when an event is received. We will be progressively adding support for more use cases, starting with the canned fault policies to start with.As an extension of this example, let us assume that the DB tier could not be brought online on the stand-by node as well and hence, the Database is faulted. Virtual Business Service will propagate this state change as well to the next higher tier. The middle tier can choose to continue to be online even when the lower tier is faulted or it can choose to pull itself offline as a reaction to the faulted event – this behavior can also be configured through Virtual Business Service.Virtual Business Service allows HA decisions to be localized at the cluster level, while adding the required glue for this information to be propagated up or down the dependency chain. All the fault propagation and reaction happens without any dependence on any external brain – VOM need not be online for the fault propagation/reaction to be executed.