And with " Okay, having used traditional disks with the containerpool I will say that that is not a good combination" I mean for the Spectrum Protect database and activelog, not for the storage of actual data. :-)
On Fri, Sep 28, 2018 at 10:06 AM Stefan Folkerts <stefan.folke...@gmail.com> wrote: > 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/ >> >
