This shared VM disk solution looks pretty neat, and I would like to use it to make database backups visible to two linux VMs running under the same VM. But when I try the vmcp command, I get a missing device msg. eg.:
# vmcp q disk Error: Could not open device /dev/vmcp: No such file or directory modprod -l shows the vmcp module loaded. Do I need a mknod command? If so, what are the major/minor nr.s? Running SLES10 sp3, kernel: 2.6.16.60-0.74.7 Roger On Thu, 2010-12-16 at 09:11 +0100, Agblad Tore wrote: > It's two different z/VM systems in two different z196. > We have this software in z/VM that enables each z/VM system to check what the > other one is using. Don't remember that abbreviation now. > That is sort of requirement, because now only one server can LINK to the > disk in write mode. We even tested a logic there both servers actually try > to LINK in write mode, the one that got it first is the current MQ. > Worked perfect, but was harder to control the traffic from app-servers. > So the switch is operator initiated now, much safer. > And by the way, we run SLES11 SP1, but it's the same for RedHat I guess. > > ___________________________________________ > 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/ Med vennlig hilsen Roger Evans Systemkonsulent ________________________________________________________________________ AutoData Norge AS - www.autodata.no - [email protected] Tlf: +47 23 17 20 30 Direkte: +47 23 17 20 46 - Faks: +47 23 17 20 50 ________________________________________________________________________ ---------------------------------------------------------------------- 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/
