Okay, having used traditional disks with the containerpool I will say that that is not a good combination since it will actually slow down the backup performance, with the filepool it can take more time to chunck and indentify after the data has landed on disk.
The thing is however that you need a lot more DB capacity with the filepool than with the containerpool and you can in fact use the newer generation read-intensive SSD's for the containerpool in most cases, we calculated it for our use cases and came to a 4-5 year lifespan. The Spectrum Protect does mostly reads. Anyway, switches to SSD's in a server (especially Intel systems) isn't expensive anymore and 2TB's worth of SSD database& activelog for the containerpool is worth about the same as 4TB worth for a fileclass type of dedup storagepool. I will even say that some acceptable database performance from 10K/10K drives is a LOT more expensive than blistering performance form a few SSD's. I don't understand what is happening with the database data that didn't want to enter the containerpool, I do remember certain types of data not being compatible, there was something (not any longer) with NDMP data I believe but just databases...never seen a problem with them pointing to the containerpool and I used the first release of Spectrum Protect that had the containerpool to backup/replicate mssql/oracle/db2 without issues and I can't think of a database that couldn't land in the containerpool, maybe somebody else knows. On Thu, Sep 27, 2018 at 9:14 PM Zoltan Forray <zfor...@vcu.edu> wrote: > We didn't do any kind of conversion since we don't have the free space. > Everything is tied up in a 500TB ISILON/NFS space that is 92% full and > nowhere to grow. > > We created a container and the directory pointing to a 15TB internal disk > space we had free. Create a new PS/Domain/MC pointing it to the container. > > Then we changed the MC of a Domain that is used for the DB backups from the > production servers and started a new DB backups on one of the production > servers. When that failed and we saw messages saying you couldn't use > containers/directories for DB backup storage, we switch gears and took an > MC for one of the small production servers/replicas and changed it to point > to the container stgpool. We started a replication on that production > server and again we saw all the incoming replica going to the nextstgpool > and nothing in the container/directory > > That was when we tried a regular client and it worked. > > Maybe it is the ISP server level? Maybe it didn't like having some of the > replicas in non-container pools? > > The lack of SSD's for DB is another reason we can't afford to use > containers on production servers. Only 1-production server has 1.9TB SSD's > and with replication and dedup it has quickly consumed 86% of it and we had > to stop dedup. > > > > On Thu, Sep 27, 2018 at 1:56 PM Stefan Folkerts <stefan.folke...@gmail.com > > > wrote: > > > Very strange, I can only say that I have done this sequence at least 5 > > times. > > First, you upgrade/migrate the replication target to the containerpool, > > then the source. > > I've never had any issues with data not landing in the pool so I really > > expect there was some anomaly happening there or a misconfiguration of > > sorts. > > > > For me the containerpool has been one of the biggest improvement on > > Spectrum Protect on the server side since replication was introduced and > I > > can only think of Virtual Environments for VMware multi-session restores > > being more important that the containerpool for my customers. > > > > As long as your using SSD's for the database (I think that's as good as a > > must-have) and have the compute power/memory to run the pools they are > > really worth the effort of looking at again because I'm sure you can do > > what you want, you can use the containerpool as a replication target from > > other pools on other servers running replication-compatible versions of > > Spectrum Protect. > > > > > > > > On Thu, Sep 27, 2018 at 4:27 PM Zoltan Forray <zfor...@vcu.edu> wrote: > > > > > We wondered about that too. But then we setup a desktop as a > client/node > > > and it backed up into the container just fine. IMHO, getting rid of the > > > node and its backups was unnecessarily complicated but we finally > deleted > > > it and the directory/container. > > > > > > On Thu, Sep 27, 2018 at 8:43 AM Stefan Folkerts < > > stefan.folke...@gmail.com > > > > > > > wrote: > > > > > > > Zoltan, > > > > > > > > That is very strange, I've used the containerpool as a replication > > target > > > > for filepools before with replication in place and this works fine. > > > > It's does not work the other way around, you can't replicate a > > > > containerpool to a filepool. > > > > I would almost say that there was a mistake made, maybe no real > storage > > > > connected to the pool or something else that went wrong because what > > you > > > > described should work. > > > > > > > > Regards, > > > > Stefan > > > > > > > > > > > > On Thu, Sep 27, 2018 at 2:35 PM Zoltan Forray <zfor...@vcu.edu> > wrote: > > > > > > > > > Stefan, > > > > > > > > > > Thank you for the reply. You said *"but for backup data on disk I > > think > > > > > nothing beats it, maybe even in any product I've ever used."* > > > > > > > > > > Unfortunately, due to the overhead/requirements/demands (as other > > > replies > > > > > have pointed out) we can NOT use it for client/node backups since > > none > > > of > > > > > our current production ISP servers have the CPU/storage (most are > > > > 32-thread > > > > > and NFS/ISILON storage) > > > > > > > > > > What we wanted to use it for was on our offsite replication TARGET > > > server > > > > > (which has 64-threads and 256GB RAM), which is used primarily for > > > > > replication of data from our onsite ISP servers as well as offsite > > > > database > > > > > backups for the onsite ISP servers (devclass server). When we > > > > > tested/created a small directory/container area on internal disk on > > > this > > > > > server, any management class we pointed to it was rejected and the > > > > incoming > > > > > replicas/DB backups were redirected to the NEXTSTGPOOL which was a > > > > normal, > > > > > devclass FILE storagepool. > > > > > > > > > > Perhaps next year when we replace one of our local ISP servers > with a > > > > much > > > > > bigger/beefier (72-threads and 120TB internal disk storage). > > > > > > > > > > On Wed, Sep 26, 2018 at 6:17 AM Stefan Folkerts < > > > > stefan.folke...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Zoltan, > > > > > > > > > > > > I'm not sure I understand your issues, we use directory > > > containerpools > > > > > for > > > > > > all but a few of our Spectrum Protect customers and it's miles > > ahead > > > of > > > > > > what the fileclass-based storagepool bring in terms of > performance, > > > > > > Spectrum Protect database impact (size wise). Yes, it isn't > capable > > > of > > > > > > certain, until then standard Spectrum Protect storagepool > functions > > > but > > > > > for > > > > > > backup data on disk I think nothing beats it, maybe even in any > > > product > > > > > > I've ever used. > > > > > > > > > > > > Of course you can't write Spectrum Protect database backups to > it, > > it > > > > > > doesn't even have a device class and it's most certainly not > > > sequential > > > > > in > > > > > > any way but normal database backups are very much able to land in > > the > > > > > > directory containerpool and you will enjoy enormous deduplication > > and > > > > > > compression benefits, much higher net savings then when using the > > > > > filepool > > > > > > at any customer site I've implemented it. > > > > > > > > > > > > So, could you please explain what you are trying to do that > doesn't > > > > work? > > > > > > > > > > > > Regards, > > > > > > Stefan > > > > > > > > > > > > > > > > > > On Mon, Sep 24, 2018 at 3:49 PM Zoltan Forray <zfor...@vcu.edu> > > > wrote: > > > > > > > > > > > > > Thanks for all the comments/suggestions and a somewhat > consensus > > to > > > > > avoid > > > > > > > directory/containers. > > > > > > > > > > > > > > We decided to at least get our "feet wet" and play with > > > > > > > directory/containers on our offsite replica-target server > (which > > > has > > > > > the > > > > > > > horsepower) only to realize everything we tried to use it for > was > > > > > > > not-allowed (DB backups from production servers and replication > > > > target > > > > > > > storage pools) and everything we directed to it was redirected > to > > > the > > > > > > "next > > > > > > > stgpool"? > > > > > > > > > > > > > > So we are confused - what can you use directory/containers for > at > > > the > > > > > > > 7.1.7.400 server level? Only real client backups? > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Sep 18, 2018 at 11:40 AM PAC Brion Arnaud < > > > > > > > arnaud.br...@panalpina.com> wrote: > > > > > > > > > > > > > > > Zoltan, > > > > > > > > > > > > > > > > If I understood well, your storage is Isilon based : in this > > case > > > > do > > > > > > not > > > > > > > > even think of using CONTAINER pools, as performance will be > > > > horrible. > > > > > > > > Not much time to talk about this, but to make a very long > story > > > > > short, > > > > > > we > > > > > > > > are about to dump/trash /resell the brand new Isilon arrays > we > > > > bought > > > > > > 8 > > > > > > > > months ago, and to replace them with direct attached storage > > > > > > (Storwize), > > > > > > > as > > > > > > > > we never reached sufficient performance levels. Cases have > been > > > > > opened > > > > > > > with > > > > > > > > IBM and EMC as well, to no result at all, beside a suspected > > > block > > > > > size > > > > > > > > issue which would refrain the Isilons to work at expected > > speed. > > > > > > > > If you plan to go for such a hardware configuration, my only > > > advice > > > > > is > > > > > > : > > > > > > > > run away, as fast as you can ! > > > > > > > > > > > > > > > > Cheers. > > > > > > > > > > > > > > > > Arnaud > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] > On > > > > > Behalf > > > > > > Of > > > > > > > > Zoltan Forray > > > > > > > > Sent: Tuesday, September 18, 2018 3:37 PM > > > > > > > > To: ADSM-L@VM.MARIST.EDU > > > > > > > > Subject: CONTAINER pool experiences > > > > > > > > > > > > > > > > We are investigating using CONTAINER pools for our offsite > > > replica > > > > > > server > > > > > > > > vs the current FILE method which is killing us with the > > constant > > > > > dedup, > > > > > > > > reclaims, etc. > > > > > > > > > > > > > > > > So, what are the "gotchas' ? We are still at V7.1.7.400 so > I > > > > figure > > > > > > we > > > > > > > > will have to do without any new features added in the V8 > > branch. > > > > But > > > > > is > > > > > > > it > > > > > > > > problematic enough at V7 to avoid it? > > > > > > > > > > > > > > > > Your thoughts? Experiences? > > > > > > > > > > > > > > > > -- > > > > > > > > *Zoltan Forray* > > > > > > > > Spectrum Protect (p.k.a. TSM) Software & Hardware > Administrator > > > > > > > > Xymon Monitor Administrator > > > > > > > > VMware Administrator > > > > > > > > Virginia Commonwealth University > > > > > > > > UCC/Office of Technology Services > > > > > > > > www.ucc.vcu.edu > > > > > > > > zfor...@vcu.edu - 804-828-4807 > > > > > > > > Don't be a phishing victim - VCU and other reputable > > > organizations > > > > > will > > > > > > > > never use email to request that you reply with your password, > > > > social > > > > > > > > security number or confidential personal information. For > more > > > > > details > > > > > > > > visit http://phishing.vcu.edu/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > *Zoltan Forray* > > > > > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > > > > > Xymon Monitor Administrator > > > > > > > VMware Administrator > > > > > > > Virginia Commonwealth University > > > > > > > UCC/Office of Technology Services > > > > > > > www.ucc.vcu.edu > > > > > > > zfor...@vcu.edu - 804-828-4807 > > > > > > > Don't be a phishing victim - VCU and other reputable > > organizations > > > > will > > > > > > > never use email to request that you reply with your password, > > > social > > > > > > > security number or confidential personal information. For more > > > > details > > > > > > > visit http://phishing.vcu.edu/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > *Zoltan Forray* > > > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > > > Xymon Monitor Administrator > > > > > VMware Administrator > > > > > Virginia Commonwealth University > > > > > UCC/Office of Technology Services > > > > > www.ucc.vcu.edu > > > > > zfor...@vcu.edu - 804-828-4807 > > > > > Don't be a phishing victim - VCU and other reputable organizations > > will > > > > > never use email to request that you reply with your password, > social > > > > > security number or confidential personal information. For more > > details > > > > > visit http://phishing.vcu.edu/ > > > > > > > > > > > > > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > Xymon Monitor Administrator > > > VMware Administrator > > > Virginia Commonwealth University > > > UCC/Office of Technology Services > > > www.ucc.vcu.edu > > > zfor...@vcu.edu - 804-828-4807 > > > Don't be a phishing victim - VCU and other reputable organizations will > > > never use email to request that you reply with your password, social > > > security number or confidential personal information. For more details > > > visit http://phishing.vcu.edu/ > > > > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://phishing.vcu.edu/ >
