[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference spezko::cluster

Title:	+ OpenVMS Clusters - The best clusters in the world! +
Notice:	This conference is COMPANY CONFIDENTIAL. See #1.3
Moderator:	PROXY::MOORE

Created:	Fri Aug 26 1988
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5320
Total number of notes:	23384

5319.0. "Mixed Versions 7.1, 6.2-1H3, 6.1" by MAASUP::PORAMBO () Tue Jun 03 1997 10:45

    
      Our customer needs to take the following cluster:
    
    	Node "A"	VAX 8820 V6.1 OpenVMS
                                    	
    	Node "B"	VAX 8820 V6.1 OpenVMS
    
    	Node "C"	AlphaServer 8200 Model 5/300
    			V6.2-1H3
    
    
    		3 seperate shadowed system disks
    		dozens of shared shadowed data disks
    
    
    
    And upgrade VMS Versions as follows:
    
    	Node "A"	VAX 8820 remian at V6.1 OpenVMS		 
                        	(because of layered product requirements)
    
    	Node "B"	VAX 8820 upgrade to V7.1 OpenVMS
    
    	Node "C"	AlphaServer 8200 Model 5/300 remains at V6.2-1H3
    			but upgraded to V7.1 in a month near for layered 
    			product requirements  
      
    
      I am concerned with the Mixed Version cluster they are attempting
    to build. In specific, I am concerned about the "cluster Compatibility
    kit" required by a V7.1 and V6.2 cluster. This configuration will have
    3 versions (7.1, 6.2-1H3, and V6.1) for a period of time. Then, it
    will run with V7.1 (alpha), V7.1 (vax), and V6.1 (vax). 
    
   1)	How would this "cluster Compatibility  kit"  play out in this 
    	environment? Should I install it on the V6.2-1H3 Alpha during the 
    	first Phase? What are the consequences of not installing the kit?
    	Would it be safe to run these three versions together?
    
    2)  Is this even worth attempting or should we just remove the V6.1
        system from the cluster?
    
    
    
    Thanks,
    
    Bob

T.R	Title	User	Personal Name	Date	Lines
5319.1		VMSSG::FRIEDRICHS	Ask me about Young Eagles	`Tue Jun 03 1997 11:53`	39
	Disclaimer: V6.1/V7.1 is not a supported migration pair. That said, let's look at what the compatibility kit has in it.. Obviously, you V6.1 system will not have these. What is the impact? - MOUNT rewrite - Basically, without all nodes running the new mount, you may still run into the well documented problems with mounting, particularly multiple mount/cluster commands not synchronizing. Overall though, it should not be any worse then you have today. - SCSI "port allocation class compatibility" - You should not run port allocation classes on any system in the cluster. The V6.1 node may not address the disks correctly and you can cause corruption on those disks. As I understand it, as long as port allocation is turned off, there is no problem. - SHADOWING rewrite - This is the biggest stumbling block. First off, when running with a mix of old and new shadowing, write logging is turned off on all disks that are mounted by old and new code. As a result, any system crash will cause full merges on those shadow sets. Aside from this, the other issue is testing... Only minor testing was done in this type of mixed version. We know that generally, the code is compatible and will work. But we did not do enough testing to say it was a migration pair. So, I guess it comes down to what your customer is comfortable with in terms of risk to the shadow sets. FWIW - There has been some talk about backporting the new Shadowing code to V6.1, but there is no schedule for that yet. I suppose that if there was enough push from the field, then perhaps it would get done sooner rather than later.. Hope this helps, jeff
5319.2		MAASUP::PORAMBO		`Tue Jun 03 1997 15:14`	17
	MOUNT rewrite If we are not experiencing these problems before the upgrade, this should not be an issue SCSI "port allocation class compatibility" We will disable port allocation class capabilities on any V7.1 system we run in the cluster SHADOWING rewrite A system crash would cause a full merge as opposed to a "minimerge". This would strictly be a performance issue, correct? Data integrity is not at stake is it? Bob
5319.3		EEMELI::MOSER	Orienteers do it in the bush...	`Tue Jun 03 1997 15:17`	4
	and just for nitpicking: officially only 2 different OpenVMS versions are allowed within the same cluster, where allowed means 'supported'. /cmos
5319.4		VMSSG::FRIEDRICHS	Ask me about Young Eagles	`Tue Jun 03 1997 17:49`	16
	Correct, the full merge is a performance issue. There are no known incompatibilites that affect data integrity. However, it was minimally tested and is not supported... If it breaks, our response can only be, "Oh well". Its up to you and your customer to do the risk/benefit analysis. If this is a big enough customer and they throw money at us to test and support a re-written V6.1 shadowing driver, there are no technical hurdles that would need to be overcome.. I suspect that MCS would have to channel this money to OpenVMS to make this happen.. Cheers, jeff