Moving TSM to AWS

[gernthefish]

We are currently running 3 on-premise, physical TSM servers that each have cloud container pools in s3. We send stgpool data over the internet to s3 and use stgpool directories for caching to help with performance. All our backup clients are on-premise, but will probably start backing up EC2 clients with large file shares. In effort to reduce our hardware footprint, we are planning to consolidate all 3 on-premise TSM servers to 1 EC2 instance in AWS. We would like to continue using s3 stg pools since they are cheaper than EBS volumes. Nodes with long-term retention will be exported to the EC2 server, and nodes with shorter retention (mostly incrementals) will just be directed to the EC2 server and start over. On-premise clients will send backup data through a VPN tunnel to the new server. That's the general plan. Not sure how this will all work, but we'll do some testing and find out. Have we overlooked anything? Anyone have advice or see any red flags?

We're also a little confused about licensing EC2 clients. Currently, we follow the "full capacity" scheme for licensing each physical hypervisor host. Per IBM's new BYOSL policy (https://www.ibm.com/software/passportadvantage/eligible_public_cloud_BYOSL_policy.html), we can assign 70 PVU per each EC2 vCPU. Can it really be that simple or do we need to change to the sub-capacity model and use ILMT (Noooooo)?

 

[marclant]

Have we overlooked anything? Anyone have advice or see any red flags?

Your plan is high level and the devil is always in the details. My only advice is that you follow the Cloud Blueprint to make sure you're sized to handle the workload you plan to push to EC2.
https://www.ibm.com/developerworks/...er/page/IBM Spectrum Protect Cloud Blueprints

 

[gernthefish]

Thanks, this is helpful. Any thoughts on licensing EC2 instances?