Document revision: 0.7 - 10/21/2003
http://asg.web.cmu.edu/isam/services/db/gridapp-eval.html
Computing Services currently supports the following database functions using Oracle 8i.
In the future, we would like to consider providing generic database service for the campus community (like what we provide in terms of email service and filesystem).
Other applications may also require Oracle database access in the future.
We currently have four sets of database servers. Each set consists of two machines: one acting as the primary and the other as the secondary/fail-over system.
The systems are currently all Sparc hardware running Solaris 2.8.
Each system has a locally attached (SCSI) RAID device.
The development system is a pair of Ultra 30s.
The "blackboard" system is a pair of E220Rs. These servers only do Blackboard but will also handle the survey tool when that goes into production. There is a third system for blackboard development.
The "portal" system is a pair of E280Rs. These servers are dedicated to the portal for preferences.
The Telecomm Pinnacle system runs on its own machine with no standby.
All other services are running off of a pair of E220Rs.
We currently have one dedicated DBA with a backup who does not do day-to-day DBA tasks.
In a pinch, we hope to be able to draw upon the DBA expertise from our colleagues in ACIS.
The current database hardware is getting old and about time to be replaced. While we do not currently have any performance issues, we also do not have a good path for adding capacity.
The primary/standby system also does not provide any form of transparent fail-over. If the primary fails, we need to force the standby to become the primary and then the primary then can become the standby. In the fail-over scenario, applications also need to be changed to point to the new primary (though perhaps we could do DNS games to get around this issue).
We propose to move all database services to the GridApp box. Each service will be configured such that the failure of a single node will not result in database unavailability.
We expect to have a dev database service with two nodes. One of which will be considered a system definable spare.
We will plan to have at least 1 domain hot-spare.
We will attach the GridApp box to the Apple XServe RAID with 2TB of space.
Benefits Summary:
This is primarily achieved via Oracle's RAC clustering. We should be able to configure things so that the failure of a single node would not result in any application noticable failure.
The other common reason for downtime would be for upgrading. We expect the GridApp to be able to do upgrades without downtime as parts of the cluster can be upgraded individually. For example, cpu upgrades should just be add the new cpu to the cluster, take the old cpu out. Oracle software upgrades can be set up a primary/backup scenario where the backup system is running the new version of Oracle. Failover to the standby once it has shown it is properly processing the transactions. If there is a problem then backout by returning to the primary.
Gridapp has also asserted that the failure of the management cpu will not result in other outages. Once the RAC clusters get set up, they will behave like 'normal' RAC clusters if there is a failure of the management cpu.
The GridApp approach does create a new failure scenario. By consolidating we run the risk that a "single system" failure will result in all the databases becoming unavailable. This risk seems relatively small since almost all components are redundant, unlike the current systems. Other than the RAID array, the blade box itself has failure characteristics the same as any given rack in the machine room.
Overall, it appears that the most common failures should be caught by redundant parts and any large-scale failure (i.e. fire) is likely to take out our other servers anyway.
The chassis can support up to 28 processors and 112GB of memory. Chassis can also be clustered together to provide an even larger computing pool. Our initial deployment is unlikely to consist of more than 14 CPUs and more than 28GB of memory. As such, the box provides plenty of headroom.
I would also expect that faster processors would be available in the future and one can upgrade to faster cpus as they become available.
We expect the GridApp software to simplify and streamline the the basic tasks and to significantly reduce the need for dealing with system failures (e.g. system disk goes down). It may also make harder tasks easier too.
This would then allow our DBA to spend time working on deploying new services or improving current services.
cpu failure and scalability is is described at http://gridapp.com/index.php/technology
more details in http://www.gridapp.com/whitepapers/D2500-Whitepaper.pdf
The largest risks are more with the company than with the technology. For example:
1. Some web pages imply support for MySQL and MS/SQL. I understand
MySQL but MS/SQL? How do you get MS/SQL to run under GOS?
Can you run MySQL and MS/SQL on the same chassis as something
running Oracle? Can the DPEs be shaed between these products?
2. We are considering using the Apple Xserve RAID as local
storage. I presume we'd set up RAID5 at the hardware level so the
RAID box would appear to the GridApp as a one or two large disks.
How do you share the storage between different databaess?
Do you just have one big filesystem?
If yes, can you control how much space a single database uses?
If no, can you dynamically grow/shrink filesystems to use
more/less space as needed?
3. TAF behavior
Minimum of 2 DPEs per database for TAF? Or can a DPE from the
Global Hot Spare pool be pulled in without the application
noticing?
4. How is memory shared? Allocated per CPU?
5. Company vitality and viability. How do we know you'll be around in
5 years? What happens if you go out of business?
- Current customer list?
- References?
- Backing/Funding?
- Competition?
6. Cooperative development/beta testing.
- Validate/Improve UI for blind DBAs
- Virtual public databases to allow users to have access to
database technology like shared filespace (be able to set
quotas, etc.)
- Our dev stuff on your dev stuff
7. Backups - what is your backup strategy? Database snapshots? We
currently use Amanda.
8. Multiple site redundancy - "Cheap" box with only a few cpus off site
in case the primary location goes down? (not cluster but
DataGuard?)
Shared backup? two different orgs using the same off-site backup
server?
9. Support -- everything through GridApp and do not need to talk to
Oracle or IBM directly? How much of the support advertised is
included in the yearly support cost?
10. Futures - Oracle 10g plans? Oracle 10g migration strategies?
11. Real costs of the unit - ? Edu discounts? Eval unit?
12. EtherChannel support for gig uplink?
13. What hooks are available for external monitoring? SNMP?
14. How do you handle Oracle licensing?
15. Security models? Changes from Oracle? Management software?
16. What do you get when you buy the product? Do we buy hardware from
IBM or is that provided?
17. What disk subsystems do you recommend? What does your internal
test and production environment use?
10/21/2003 - 0.7 - wcw - add more questions 10/21/2003 - 0.6 - wcw - add items to question (5) feedback from kern 10/20/2003 - 0.5 - wcw - update from mgr meeting 10/20/2003 - 0.4 - wcw - updates from jackson 10/17/2003 - 0.3 - wcw - added comments from tgd 10/16/2003 - 0.2 - wcw - Added more detail in section 2 10/15/2003 - 0.1 - wcw - Initial revision