10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

C H A P T E R 14Storage LayoutIn <strong>Oracle</strong> 10gR1, <strong>Oracle</strong> introduced Automatic Storage Management (ASM) and changed the way wethink of managing database storage. <strong>Exadata</strong> is tightly integrated with ASM and provides the underlyingdisks that have traditionally been presented to ASM by the operating system. Looking at all the variousintricacies of cell storage can be a little daunting at first. There are several layers of abstraction betweenphysical disks and the ASM disk groups many DBAs are familiar with. If you’ve never worked with<strong>Oracle</strong>’s ASM product there will be a lot of new terms and concepts to understand there as well. InChapter 8 we discussed the underlying layers of <strong>Exadata</strong> storage from the physical disks up through thecell disk layer. This chapter will pick up where Chapter 8 left off, and discuss how cell disks are used tocreate grid disks for ASM storage. We’ll briefly discuss the underlying disk architecture of the storage celland how Linux presents physical disks to the application layer. From there, we’ll take a look at theoptions for carving up and presenting <strong>Exadata</strong> grid disks to the database tier. The approach <strong>Oracle</strong>recommends is to create a few large “pools” of disks across all storage cells. While this approachgenerally works well from a performance standpoint, there are reasons to consider alternative strategies.Sometimes, isolating a set of storage cells to form a separate storage grid is desirable. This providesseparation from more critical systems within the <strong>Exadata</strong> enclosure so that patches may be installed andtested before they are implemented in production. Along the way we’ll take a look at how ASM providesfault resiliency and storage virtualization to databases. Lastly, we’ll take a look at how storage security isimplemented on <strong>Exadata</strong>. The storage cell is a highly performant, highly complex, and highlyconfigurable blend of hardware and software. This chapter will take a close look at how all the variouspieces work together to provide flexible, high-performance storage to <strong>Oracle</strong> databases.<strong>Exadata</strong> Disk ArchitectureWhen Linux boots up it runs a scan to identify disks attached to the server. When a disk is found, the O/Sdetermines the device driver needed and creates a block device called a LUN for application access.While it is possible for applications to read and write directly to these block devices, it is not a commonpractice. Doing so subjects the application to changes that are complicated to deal with. For example,because device names are dynamically generated on bootup, adding or replacing a disk can cause all ofthe disk device names to change. ASM and databases need file permissions to be set that will allowread/write access to these devices as well. In earlier releases of ASM this was managed by the systemadministrator through the use of native Linux commands like raw and udev. <strong>Exadata</strong> shields systemadministrators and DBAs from these complexities through various layers of abstraction. Cell disksprovide the first abstraction layer for LUNs. Cell disks are used by cellsrv to manage I/O resources atthe storage cell. Grid disks are the next layer of abstraction and are the disk devices presented to thedatabase servers as ASM Disks. Figure 14-1 shows how cell disks and grid disks fit into the overall storagearchitecture of an <strong>Exadata</strong> storage cell.467

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!