Hi Steve
How many nodes and what are the amount of data?
We have 500 servers of which 250 are large unix servers. We normally have
a daily incremental backup of about 5-6TB every night. All theese nodes
are backing up its data to a HACMP cluster based on pSeries 660 machines
with 4GB of RAM, 4 processors(675Mhz), 2 I/O drawers and 8 FC HBA:s. We
have a normal throughput rate of about 250-300MB/s during migration and
backup storage pool processing and about 100MB/s during backup to
disk/tape (2 Gigabit Etherchannel adapters). The total amount of data is
300TB.
We have this far no performance issues, and do not have any issues with
either CPU utilization or disk wait.
I dont believe you would need a p690 machine to backup the data. We could
without a problem double the amount of data transferred each night without
issues. We would probably be forced to add more hardware though, like
disk(resident on HDS 9960 today) and FC HBA:s aswell as tape
drives(9840B/9840C).
My guess would be that you could get away with alot smaller machine. All
you need to do is optimize the I/O throughput by using I/O drawers, FC
HBA:s and more Gigabit Etherchannel adapters. If you have far more data
than us, you would probably need to have more RAM and CPU:s(perhaps 8GB of
RAM and 4 Power5 CPU:s instead of the older processors we're using).
The price for that configuration would be alot lower than the one for a
HACMP-based p690 cluster.
The problem you will face if you start de-centralizing your environment is
the amount of time you need to put on administration. This cost will,
calculated over several years, be alot higher than the one for hardware.
It will also be harder for you to detect minor issues, or hardware that is
beginning to fail. The issue with hardware upgrades will also be a cost
that should be taken in account. You will no longer be upgrading a single
system, but doing hardware/software upgrades to different systems that
cannot be shared among the systems.
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Chef Utveckling & Drift
Exist i Stockholm AB
Propellervägen 6B
183 62 TÄBY
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2004-10-15 07:40
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
TSM as application on windows cluster
Hi all,
I'm designing a TSM solution for our enterprise data centre. The EDC
consists of two physical datacentres with appropriate smarts to make them
appear as one big logical entity from both the SAN and LAN perspective
We currently run a single TSM server on AIX which backs up a portion of
the application nodes in the EDC.
We don't currently have any apps that can automatically fail over, but we
will have some real soon. The reason for the TSM redesign is that we are
going to put TSM in many places around the state, and that includes
backing up all of the enterprise datacentre rather than just the odd bits
that we do now. The rest of the state will be running on windows, so we
are keen to use windows in the EDC also. The configuration manager will
also run in the EDC.
Is anyone running TSM server as an application in a geographically spread
active/active windows cluster? Did you have any issues getting this to
work? Is it reliable both in normal operation and in failover?
I have the option of a p690 AIX/Veritas cluster solution or Sun
F15K/Veritas cluster, but both of those seem unreasonably expensive, and
will move away from a Windows standard approach state wide. Any insight
will be helpful.
Thanks
Steve.
Steve Harris
TSM design Guru (Ha! - faking it anyway)
Queensland Health, Brisbane Australia
***********************************************************************************
This email, including any attachments sent with it, is confidential and
for the sole use of the intended recipient(s). This confidentiality is
not waived or lost, if you receive it and you are not the intended
recipient(s), or if it is transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of
this email is prohibited. It may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this
email in error, you are asked to immediately notify the sender by
telephone or by return email. You should also delete this email and
destroy any hard copies produced.
***********************************************************************************
|
