Oracle's Version of the Grid Now that we have defined the characteristics of a computing grid, let us list the essential components of such a gridspecifically, Oracle's version of such as grid. In no particular order, the components of such a grid are as follows: Computing resources such as servers, including their components such as CPUs, memory, and self-contained internal hard disks containing the operating system and swap. Storage resources such as SANs, NAS, and even simple disk farms in some form of RAID (Redundant Array of Inexpensive Disks). It is important to note that these storage resources should be exposed to and be seen by all the servers. Networks connecting servers. Usually, these are high speed, geographically clustered networks with servers connected to each other in a local enterprise grid. There are also cases where a grid consists of servers connected over long distances, but they usually do not access shared storage components. Clustering software that allows these computing resources to work together, see the same storage devices, and access them simultaneously. Clustering software also includes the capability to provide high availability by enabling server failover. Application software that is cluster or grid aware. This includes software at the application front end such as Web servers and J2EE containers as well the database back end.
The way these components fit together is shown in Figure 18.1. The highlighted portions show where technology and components from Oracle Corporation fit into the computing grid. First come the load-balanced and clustered application servers, which may include Oracle's Application Server 10g (previously Oracle iAS). The applications themselves could include enterprise resource planning (ERP) applications such as the Oracle E-Business Suite (also known as Oracle Applications 11i). At the next level are the highly available clustered servers that run Oracle Database 10g RAC. Included in the services at this layer is Oracle Database 10g Cluster Ready Services (CRS). These servers in turn are back-ended by storage area networks accessed via dual-network storage switches. The disks themselves are presented to the Oracle Database 10g RAC instances as many Oracle Database 10g ASM disk groups. From this figure, it is obvious that Oracle Corporation can provide software components at almost all levels of the grid. Figure 18.1. A typical computing grid. 
This architecture is actually familiar in most enterprises. So how is this picture different, and in what way is it a grid? The answer lies in the capability of each of these Oracle components to enable one or more requirements of the computing grid, as explained in the previous section: High availability. Oracle Database 10g RAC provides high availability by presenting multiple database instances that can access the same set of data and in turn present this data to a pool of application servers running Oracle Application Server 10g. Failovers are automatic and can occur at the instance level or application server level. These failovers could be caused by both hardware and software components. Technologies such as Transparent Application Failover (TAF) can make such failovers transparent to users. You saw in detail how this is made possible in Part IV, "Scaling and Availability with Oracle Database 10g." High performance. Although individual Oracle Database 10g instances can provide high throughput and performance by themselves, there is still a point in the curve when even the best server cannot provide the level of performance required for a very large number of users. Oracle Database 10g RAC enables horizontal scalability by adding computing nodes or instances that access a common database. When combined with remote terminal services such as Citrix, these instances can provide the same kind of rich-client performance, even for remote locations and individuals that use dial-up lines. You saw how Oracle Database 10g could provide this in Part III, "Tuning Oracle Database 10g," as well as in Part IV, "Scaling and Availability with Oracle Database 10g." High resiliency. The capability to quickly recover from natural, technical, and man-made disasters is provided by the various components of Oracle Database 10g. For example, ASM has built-in disk protection that can enable a database to continue functioning despite disk failures. Oracle flashback features protect from user and administrator errors. Oracle Data Guard provides for setting up physical and logical standby copies of the primary database at an alternate, geographically remote site. Oracle RMAN simplifies recovery by automating the process and thus preventing lag due to administrators working out manual procedures. As well, RMAN can stage the recovery directly from the flash recovery area so that tape restoration time is saved as well. You saw details of how this is made possible in various parts of this book. Hardware independence. The provision of transportable tablespaces provides for hardware vendor independence. For example, you might front-end the grid with smaller independent Oracle databases on Linux servers, consolidating data via transportable tablespaces to a larger Sun or HP box. Virtualization at all layers. Rather than make static ties that determine and isolate where an application and its corresponding data resides, Oracle Database 10g's grid-aware products, including ASM, RAC, and application layers, virtualize all the resources shown in Figure 18.1. Profiled resource usage. At almost all levels in the technology stack, Oracle Database 10g and its related products in the grid arena can provide the required quality of service (QoS) for the user or type of application. For example, an Oracle Database 10g instance can be configured to provide the right level of computing resources such as CPU and I/O limits to identified sets of users or processing via the Resource Manager. Although not fully enabling "pay-per-use," this does lay the framework for presenting user communities with a means of paying for and obtaining the right levels of service. Self managing and self healing. Due to the sheer number of components and the complexities involved in connecting all of them together, the grid should have some self-managing and self-healing capabilities. We have seen in various places in this book how Oracle Database 10g can diagnose, alert, and optionally heal itself of issues, thus drastically reducing the administrative burden of managing very large numbers of instances.
|
