• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
David Walker Page 1
BUILDING LARGE SCALEABLE CLIENT/SERVER SOLUTIONS
David Walker European Oracle User Group, Firenze, Italia, 1995
Summary
The replacement of 'Legacy' systems by 'Right-Sized' solutions has lead to a growth inthe number of large open client/server installations. In order to achieve the requiredreturn on investment these solutions must be at the same time flexible, resilient andscaleable. This paper sets out to describe the building of an open client/server solution by breaking it up into components. Each component is examined for scaleability andresilience. The complete solution, however, is more than the sum of the parts andtherefore a view of the infrastructure required around each element will be discussed.
Introduction
This paper will explore the proposition that large scale client server solutions can bedesigned and implemented by de-constructing the architecture into quantifyablecomponents.This can be expressed as a model based on the following four server types:Database Server Application Server Batch Server Print Server Each of these components must have two characteristics. The first characteristic isresilience. Having a single point of failure will mean that the whole solution may fail.This must be designed out wherever possible. The second characteristic is scaleablity.All computers have limitations in processing power, memory and disk capacity. Thesolution must take into account hardware limitations and be designed to makeoptimum use of the underlying platform.It is assumed that the system described will be mission critical, with over two hundredconcurrent users and a database not less than ten gigabytes. The growth of these sites tothousands of concurrent users and hundreds of gigabytes of data is made easier bydesigning the system to be scaleable.
 
David Walker Page 2
 
David Walker Page 3
Database Server
The Database Server is the component traditionally thought of as 'The Server'. It is herethat the Oracle RDBMS deals with requests, normally via SQL*Net. A resilientDatabase Server will be spread over more than one node of a clustered system usingOracle Parallel Server [OPS] in case of hardware failure within a single node.A clustered system is one where homogeneous hardware nodes are linked together.They share a common pool of disk, but have discrete processor and memory. There is aLock Manager [LM] which manages the locking of data and control objects on theshared disks. The Lock Manager operates over a Low Latency Inter-connect [LLI](typically Ethernet or FDDI) to pass messages between nodes. The disks are connectedto all nodes through a High Bandwidth Inter-connect [HBI] (typically SCSI).Clustering a system provides additional resilience, processing power and memorycapacity. However, since the complete database must be available on shared disk, themaximum database size can be no greater than the maximum database size configurableon a single node.The disks within such mission critical systems are also required to meet the resilienceand scaleability criteria. The Redundant Array of Inexpensive Disks [RAID]technologies provide a solution. RAID level 0 provides striping across many disks for high performance, but it is fault intolerant. RAID level 1 implements disk mirroring,where each disk has an identical copy. RAID level 5 offers striping with parity. WhilstRAID level 5 is cheaper than full mirroring there are performance issues when a failureoccurs. In the type of system that is being examined in this paper the solution is to useRAID 0 and RAID 1; striping and mirroring.The basic level of resilience is to start an OPS instance on each of two nodes. All usersare then connected to one node, the other node participates in the OPS database but noconnections are made to the database. When the active node fails, all users migrate tothe alternate node and continue processing. The precise method of migration willdepend on the network protocol in use. Any existing network connections will have to be established to the alternate node and the current transaction will be lost. Theconnection will require users to be directed to the alternate node. This would typically be dealt with transparently from the 'Application Server' (See below).As the application grows the load may exceed the processing power, or memorycapacity of a single node. At this point the users can be distributed over multiple nodes.In order to do this the application must have been designed with OPS in mind. Thisrequires that, where possible, the applications are 'partitioned'.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...