• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Moving TSM to AWS

gernthefish

ADSM.ORG Member
#1
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)?
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 16 18.8%
  • Keep using TSM for Spectrum Protect.

    Votes: 52 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.8%
  • Other (please comement)

    Votes: 7 8.2%

Forum statistics

Threads
31,451
Messages
133,985
Members
21,549
Latest member
idhelmyy
Top