Sorry, forgot first question here...:( I actually don't know the exact method here, I did not set it up just prepared the diskswitching. But we don't use VIP, I think they just change the app-servers config to connect to the other MQ system.
/Tore ___________________________________________ Tore Agblad Volvo Information Technology Infrastructure Mainframe Design & Development, Linux servers Dept 4352 DA1S SE-405 08, Gothenburg Sweden Telephone: +46-31-3233569 E-mail: [email protected] http://www.volvo.com/volvoit/global/en-gb/ -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Marcy Cortes Sent: den 15 december 2010 18:37 To: [email protected] Subject: Re: Shared filesystem in redhat Agblad, Do you configure both MQ server names in your app server? Or do you move host names to the new server? Or use VIP or something? Do you have anything in place to prevent write links from both servers? Are they on the same VM system? Just curious, we have a MQ MI implementation in proof of concept now but set up with NFS. Marcy -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Agblad Tore Sent: Wednesday, December 15, 2010 7:37 AM To: [email protected] Subject: Re: [LINUX-390] Shared filesystem in redhat Agree with that NFS has serious drawback, especially when you need redundant (duplicate servers) Here is just a hint to get rid of that problem when using MQ: We needed a redundant solution for MQ, who stores for example it's queues in normal files. The recommendation when you have two (or more) MQ servers was to use NFS mounted files.... and there goes redundancy :( We finally ended up with having two servers with MQ installed, but only active in one of them. And both appl servers(redundant) using them called the one active. The MQ server choosen as active at start did VMCP LINK 800 as writable, dasd_configure 0.0.0800 1 1 (we used DIAG) and mount it before starting MQ. When stopping MQ we added umount, dasd_configure 0.0.0800 0 0 and VMCP DET 800 You need to put a wait for 10 seconds since the dasd_configure start the requested action async. Now we can switch MQ between the two servers making it typically redundant. It's very stable and we have normal realdisk performance. ___________________________________________ Tore Agblad Volvo Information Technology Infrastructure Mainframe Design & Development, Linux servers Dept 4352 DA1S SE-405 08, Gothenburg Sweden Telephone: +46-31-3233569 E-mail: [email protected] http://www.volvo.com/volvoit/global/en-gb/ -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Richard Troth Sent: den 14 december 2010 16:21 To: [email protected] Subject: Re: Shared filesystem in redhat Good points. I did not mention your #5 because it affects shared DASD too and was trying to contrast NFS and shared disk. -- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Tue, Dec 14, 2010 at 10:12, Patrick Spinler <[email protected]> wrote: > On 12/14/2010 07:47 AM, Richard Troth wrote: >> >> Having just recommended NFS, I must respond to this question. YES, >> there are reasons why one might NOT want to use it. >> >> NFS is my first choice for shared RW storage or for any shared storage >> where you don't have a hardware sharing option. Caleb can share the >> disks at the HW level, so that is preferred. >> >> So why or when would one not want to go NFS? >> >> #1 - NFS firstly requires the network. The sharing systems cannot >> operate independently. (They cannot be isolated. Sometimes people >> isolate systems. Lots of reasons for that; do I need to enumerate? >> And don't get me started about port-grained access controls in >> switches and VLANs.) The requirement for the network also affects the >> sequencing at startup. Your NFS-resident content cannot be there >> until your network is fully operational. >> >> #2 - NFS means that one server has to "own" the data. That one server >> becomes another single point of failure. Even apart from failure, >> access times are different on all the other systems so you may find >> performance numbers out of balance. "It depends." >> >> #3 - (related to #2) NFS and NIS historically are the two services >> which can lock-up a system tighter than anything else. If the hosting >> NFS server goes away, or if there is some other problem between there >> and the client(s), then the client(s) are stuck until things are >> restored. >> > > #4 - Security issues. While there are options in NFSv4 protocol to do > secure authentication (and I believe, secure transmission) NFS defaults are > pretty open, both with regard to authentication and transmission. > > #5 - System UID/GID numbers. This is not a bad thing to do anyway, but it is > something to be aware of. Running NFS will force you to keep your UID and > GID numbers coordinated across all systems and accounts that access that > storage. Best to just set up a LDAP service and keep all your accounts in > sync everywhere. (Be aware that different unix like OS's default common > service accounts like apache to different values -- problems here) > > BTW -- to partially alleviate issue #3, we've moved to using our automounter > to mount all of our NFS storage on every client that needs it. It's not a > complete fix, but it helps a lot. > > I really really wish that there was a unix network filesystem that combined > e.g. AFS's reliability, client caching, distributed redundancy and secure > authentication with NFS's ubiquitousness, UNIX style security semantics and > ACL's. IMHO all the network filesystems out there have significant > drawbacks. > > -- Pat > > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
