On 1/9/2012 2:27 PM, Alan Brown wrote: > On 09/01/12 09:36, Fabio M. Di Nitto wrote: > >>> RH's advice to use is to "Big Bang" it. >> >> It´s not much of an advice, as RH does not officially support this >> upgrade method. > > Indeed, but scheduling downtime in a 24*7*365.254 operation like space > science ftp servers is tricky. (1: You can't please everyone all the > time and they all believe their priorities are of earth-shattering > importance. 2: You can't schedule downtime during nights or vacation > periods as the people concerned tend to decide this is the best time to > run heavy duty batch processing that's due first thing Monday morning.) Yeah you are not telling me anything new :) Something i forgot to mention in the other email, is that for example, you can just move the LUNs from your SAN from one cluster to another assuming you are running GFS2 and that will work. So in theory the downtime would be reduced to just stop old cluster -> rewire the SAN -> start new cluster. > >> The amount of changes in the cluster software between EL5 and EL6 are a >> lot less intrusive at system level. I can´t really say for sure for the >> entire OS, since the upgrade doesn´t involve only RHCS. > > Aye. > > In this case the boxes are ONLY used as NFS fileservers because running > anything else on them which touched the GFS(2) FSes resulted in file > corruption (which is a case of "NFS vs everything else", more than > clustering itself.) > Possibly this is one of the use case where upgrading could work. > It would be _nice_ to have NFSv4 support working and supported in a GFS2 > cluster. Steven can answer to this one.. but I think the point is more active/active vs active/passive (IIRC from previous discussions). Fabio -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
