First off, we do not know how anyone can run replication of data from a FILE base storagepool (yes, we know that CONTAINERS fixes everything🙄) to another server. Every attempt we have made usually ends up in a mess that we have to undo/cleanup. We find it is very slow (10G on both ends) and the replication processes never seem to finish/end.
We have observed that no matter how many or how few replication sessions we start, most of them seem to go idle/wait (e.g. MAXSESSIONS=10 starts 20-sessions to the target server of which 16+ become idle eventhough there is 4TB to replication. Since we need to get off magnetic tape (moving to a new building with restricted space so existing ATL has to go!), we have been using the offsite server as Virtual Volumes and creating offsite backups to it. This was working pretty well until we started experiencing server crashes/cores after upgrading to 8.1.14 (support confirmed a bug - sent us an eFix for it - we were continuing to have intermittent crashes - support discovered another related bug via RECONCILE VOLUMES command - just installed another eFix that is supposed to address the crashes). While waiting for a fix for the original server problem, we decided to try to transition back to replication - only to have more problems than the crashes. We have had to bounce the target and source servers multiple times due to replication sessions that won't go away/end as well as the performance issues I mentioned above. Did I mention the issues with the 8.1.15 Linux client also related to replication? Since we have the shared stgpools/reconcile volumes eFix (8.1.14.110) installed on all servers, we have decided to go back to virtual volumes. Now back to the subject of this post. Right now I have 4-replication sessions on the target server that say they are doing something (i.e. not in a WAIT), but in reality have been hung since August 1st (we had installed the eFix but forgot to disable the admin command that kicks off replication). There are no replication sessions on the source server. All attempts to cancel the ghost sessions on the target server say they can't be canceled. So before we bounce it one-more-time, we were wondering if there is a super-secret "cancel session with force" we are not aware of? -- *Zoltan Forray* Enterprise Backup Administrator VMware Systems Administrator Enterprise Compute & Storage Platforms Team VCU Infrastructure 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/ <https://adminmicro2.questionpro.com>
