Chris,
This seems like very sound logic. In contrast our priority is
definitely the 1st & 2nd type of restore. In fact we would be able to
cope with the 3rd type, but it would be slooow. We have all primary
pools (mostly collocated) copied into one copy pool (no collocation)
for offsite storage. So although all data would be recoverable, we
would take quite a number of days to regenerate the primary pools,
which would then give decent restore performance & only for a few
clients at a time.
As you say the design of an ADSM setup needs to be done in full view of
the business requirements for restoring the data.
Cheers,
Simon
----------
| From: c.jordan / mime, , , c.jordan AT ELSEVIER.CO DOT UK
| From: c.jordan / mime, , , c.jordan AT ELSEVIER.CO DOT UK
| To: ADSM-L / mime, , , ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: ADSM Bottleneck
| Date: Friday, 03 September, 1999 5:51PM
|
| Trying to ignore the NT / UNIX battles, and just reporting our thoughts and
| (possibly erroneous) conclusions.
|
| Thought: A backup is useless. It takes time; its an intrusion; no body needs
| it.
| HOWEVER the reason for taking backups is so that we can do restores.
|
| We see 3 types of restores: One is the daily "I've lost my file". These are
| a pain but a necessary fact of life. The second is the complete restore of a
| single server. The third is the complete restore of the whole data centre.
| Our business has decreed that the third should have priority (our building
| is right next door to a training airport!).
|
| So for a "speedy" datacentre restore we need multiple parallel restores
| happening at the same time. We get this from multiple, smaller, boxes.
| Our Disaster Recovery site has no server hardware in it. The computers are
| built when we invoke the DR plan. Our DR site supplier can provide fully
| configured and working NT boxes quicker than they can provide UNIX boxes.
|
| Therefore, in our situation, we use multiple NT boxes for the ADSM Server
| systems.
|
|
| Cheers, Chris
|
| -----Original Message-----
| From: Simon Watson [mailto:simon.s.watson AT SHELL.COM DOT BN]
| Sent: 20 August 1999 11:15
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: ADSM Bottleneck
|
|
| I can certainly see the merit in your approach. It also tends to
| reduce the dependancy on a single point of failure.
|
| However, what would worry me is the Capital & Operating cost of this
| approach. The costs will increase proportionally as the number of
| servers increases. In our environment (using AIX) we are finding it
| quite easy to scale up to manage increasing volumes of data, using a
| single server, without significantly increasing the cost. In fact the
| bigger we are getting the cost per MB of data being backed up/stored is
| reducing which is quite helpful in attracting customers and
| centralising all our backups in the organisation. This in turn is
| reducing the overall cost to the company of providing a Storage
| Management service.
|
| The other advantage of a larger server is that it can be designed to
| make more effective use of resources than can many separate servers.
| Much like a four lane highway can carry a lot more traffic than 4
| single lane roads. Restore performance can also be significantly
| improved as a single restore can make use of the resources of the
| complete large system (depending on design of pools etc.), rather than
| only getting the resources of one of a number of smaller systems.
|
| In our case AIX is a clear winner over NT, simply because it is more
| scallable & offers better performance, and in fact the Total Cost of
| providing the solution is cheaper than it would be with NT. Of course
| if a single NT server offers sufficient performance then it is a very
| good choice.
|
| Regards,
| Simon
| ----------
| | From: c.jordan / mime, , , c.jordan AT ELSEVIER.CO DOT UK
| | To: ADSM-L / mime, , , ADSM-L AT VM.MARIST DOT EDU
| | Subject: Re: ADSM Bottleneck
| | Date: Friday, 20 August, 1999 5:47PM
| |
| | We used the building block approach. Designing a "balanced" (we hope!)
| | system of a certain size. Each of these blocks can back up about 20 to 30
| | clients with a total disk usage of about 2 TBytes (we hope!). When we have
| | more clients to back up, then we add another building block - which
| includes
| | a new NT server, memory, disk cache, tape library etc.....
| | This spreads the load, requires less ADSM tuning knowledge, and allows
| easy
| | to understand expansion in the future.
| |
| | Cheers, Chris
| |
| | -----Original Message-----
| | From: Rodrigo Cordovil Gazzaneo [mailto:rgazzaneo AT INFOLINK.COM DOT BR]
| | Sent: 20 August 1999 03:50
| | To: ADSM-L AT VM.MARIST DOT EDU
| | Subject: Re: ADSM Bottleneck
| |
| |
| | NT is your bottleneck !
| |
| | Sorry for the strong way of saying, but scalability is not the strong
| point
| | for NT, so adding processors is not closer to linear (ideal) performance
| | growth.
| |
| | I am not sure, but NT licensing for SMP systems and the NT system itself
| | may not be worth the performance gain.
| |
| | If I were you I would add memory and try to distribute I/O through many
| | disk/tapes controllers. Probably results will be a lot better than just
| | adding another CPU.
| |
| | good luck,
| |
| | Rodrigo
| |
| | >We are about to spec out a new ADSM server running NT on the Intel
| platfor
| | >We are interested in opinions of what are the main bottlenecks for ADSM
| | >performance. For instance, would adding multiple processors increase
| | >performance (especially ADSM DB) or is memory more important. Thanks in
| | >advance.
| | >Seth Forgosh
| |
|
|
