Ok, thanks David and Matthew. The reply from David would be indicate a 'no go' since I would need a spoke to also be a hub for this to work I guess. (spoke from an HQ perspective and a hub from a BO local perspective)
Or is an OC instance only a real hub when it receives data from spokes, In that case it might not be a problem. >I decided to give it whirl and added one of my satellite TSM servers to my head office OC about ten minutes ago. I'll let you know how it goes. Great, I hope it doesn't mess stuff up for you but yes, please let us know how that goes. :-) On Wed, Sep 9, 2015 at 4:06 PM, Matthew McGeary < [email protected]> wrote: > Hello Stefan, > > I've been wanting to do the exact same thing myself but haven't tried it > because I thought that the documentation for the OC stated it was not > possible. Your email prompted me to look again and now I can't find > anything to indicate it isn't possible. > > As I understand it, adding a server into the OC does the following: > - defines the spoke server on the hub server just like doing a > server-server communication setup for config or virtual volumes > - defines an administrative account on the hub server to perform commands > for the OC > - this account is unique to each hub server, which means you can > potentially have more than one account running on a spoke > - sets server alerts and triggers on the spoke based on the hub config > > The issue I can see is that if the OC settings and alerts for a spoke are > stored on the spoke, rather than on the hub, conflicts will arise between > the hub server in your central location and the OC running on the spoke. > Both will attempt to set certain flags and override each other based on the > whichever one did the last operation. This could get confusing. If, > however, things like 'At Risk' settings and the like are stored within the > hub server itself, there should be no conflicts. > > I decided to give it whirl and added one of my satellite TSM servers to my > head office OC about ten minutes ago. > > I'll let you know how it goes. > __________________________ > > *Matthew McGeary* > Technical Specialist - Infrastructure > PotashCorp > T: (306) 933-8921 > *www.potashcorp.com* <http://www.potashcorp.com> > > > > > > From: Stefan Folkerts <[email protected]> > To: [email protected] > Date: 09/09/2015 06:42 AM > Subject: Re: [ADSM-L] A few questions about managing multiple > Spectrum Protect servers with the Operations Center > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > ------------------------------ > > > > Hi David, thanks for your reply. > > >I believe that the OC will want to create a named account (default name) > on each TSM server it monitors (it's ok to say TSM, I'm not IBM). This > password would need to be the same across all the TSM servers. I think > that's going to be the problem for you but I could be wrong. > > But the admin picks the name. Couldn't I create one account for the HQ OC > instance that connects to all the servers and one account per branch office > that connects only to the local branch office instance? > > I don't know why that would not work. > > > > > > > On Wed, Sep 9, 2015 at 2:10 PM, Nixon, Charles D. (David) < > [email protected]> wrote: > > > I believe that the OC will want to create a named account (default name) > > on each TSM server it monitors (it's ok to say TSM, I'm not IBM). This > > password would need to be the same across all the TSM servers. I think > > that's going to be the problem for you but I could be wrong. > > > > --------------------------------------------------- > > David Nixon > > System Programmer II, Enterprise Storage Team > > Carilion Clinic | 451 Kimball Avenue | Roanoke, VA 24016 > > 540.224.3903 (Work) > > 540.525.8000 (Mobile) > > > > ________________________________________ > > From: ADSM: Dist Stor Manager [[email protected]] on behalf of Stefan > > Folkerts [[email protected]] > > Sent: Wednesday, September 09, 2015 6:03 AM > > To: [email protected] > > Subject: [ADSM-L] A few questions about managing multiple Spectrum > Protect > > servers with the Operations Center > > > > Hi all, > > > > I am looking into some things regarding the managing/monitoring of > multiple > > TSM (sorry, Spectrum Protect) servers using the Operations Center. > > > > I can build a test setup to look into it but that is not worth the effort > > if somebody here can tell me it's not going to work. :-) > > > > Let's asume I have a HQ and 5 branch offices. > > > > I configure the branch offices to use Spectrum Protect replication to the > > HQ location. > > > > I want the branch offices to be able to monitor and administer their > local > > Spectrum Protect server using a local OC setup on the BO server (version > > 7.1.3) but not see the server in the HQ. > > > > Next I want the OC install on the Spectrum Protect server in the HQ to > have > > a connection with the server in HQ but also al 5 of the branch offices. > > > > I can use seperate Spectrum Protect admin accounts. > > VPN access is all configured. > > It's just about being able to connect a Spectrum Protect server to > multiple > > instances of the Operations Center basically and creating something that > > looks like multi tiering this way. > > > > Any feedback is welcome, thanks in advance! > > > > Regards, > > Stefan > > > > ________________________________ > > > > Notice: The information and attachment(s) contained in this communication > > are intended for the addressee only, and may be confidential and/or > legally > > privileged. If you have received this communication in error, please > > contact the sender immediately, and delete this communication from any > > computer or network system. Any interception, review, printing, copying, > > re-transmission, dissemination, or other use of, or taking of any action > > upon this information by persons or entities other than the intended > > recipient is strictly prohibited by law and may subject them to criminal > or > > civil liability. Carilion Clinic shall not be liable for the improper > > and/or incomplete transmission of the information contained in this > > communication or for any delay in its receipt. > > > >
