INFO-VAX Mon, 07 Jul 2008 Volume 2008 : Issue 377 Contents: Re: NTP on OpenVMS using TCPIP services Re: NTP on OpenVMS using TCPIP services Re: Question about NTP.CONF master and local-master commands Re: Show of support for Distributed NetBeans Re: VMS SAN Primer Re: VMS SAN Primer Re: VMS SAN Primer Re: VMS SAN Primer Re: VMS SAN Primer ---------------------------------------------------------------------- Date: Mon, 7 Jul 2008 10:29:45 -0700 (PDT) From: Rich Jordan Subject: Re: NTP on OpenVMS using TCPIP services Message-ID: On Jul 4, 12:35=A0pm, "Richard B. Gilbert" wrote: > baldrick wrote: > > Spooky! As AEF's query comes in, I seek clarification on what I'm seein= g... > > > Versions FWIW VMS 7.3-1, TCPIP 5.3 eco 2, also OpenVMS 8.3 (Alpha) and > > TCPIP 5.6, time server Windows Server 2003, and Windows XP professional= . > > NTP version on VMS is 4.1 > > > NTP on this Alpha was working quite well with a UNIX NTP server, until > > it was retired. > > > Scenario is, using the documentation for HP's TCPIP services I set up > > NTP naming two Windows servers as "peers". Debugging this using > > TCPIP$NTPQ shows a REJECT status in the "associations" display. > > Increasing the log level using the logical TCPIP$NTP_LOG_LEVEL =A0(to 3= ) > > just seemed to indicate nothing was happening to correct the time. > > > So I replicated the scenario at home, and used my XP Pro system as a > > server, and set up the same way got exactly the same symptoms. I enable= d > > detailed logging on the Windows side (microsoft technet articles) and > > saw the requests coming in, and even the correct value / difference in > > time was reported and the stratum was 0. What I had proved was that it > > wasn't a firewall or authentication issue. I was now in a position to > > start looking at the NTP CONF file. > > > When i changed the peer to server and the IP address, all of a sudden > > NPTQ started looking different and the RUN logs again had more detail > > about offsets. > > > The line in the TCPIP$NTP.CONF file was: > > > peer 192.168.0.150 > > > changed to > > > server 192.168.0.150 > > > where that address is the IP of the time server of course. > > > It took a while but eventually the Windows time service log showed a > > stratum of 3 (then later 5) and within 2 hours the time was synchronize= d. > > > Then I did the same on the systems that I was seeing the original > > behaviour, and low, behold, its working now. > > > SO the question is, is this an error in the documentation (or not very > > clear) or something introduced by using Windows that "peer" worked for > > the UNIX NTP server, but Windows (the replacement NTP server) requires > > "server" instead? > > > What is the authentication about? I see the program to create the keys > > but in what circumstances is it used? This was one thought why I was > > seeing the REJECT message in the debugging. > > > Anything else relevant here? I'll also accept that I may have not fully > > understood the documentation, or even the NTP process. > > > (Also documented so googlers may seek details) > > "peer" in NTP speak refers to systems at the same NTP stratum that can > serve time to each other. =A0Ideally the peered systems would each use at > least one unique time source. > > Windows does not offer NTP. =A0It has an SNTP client and should be used > only as a leaf node. =A0It WILL serve time and, if you allow it to do so, > you deserve whatever happens!! > > There IS an NTP implementation for Windows. =A0If you need it, go tohttp:= //www.ntp.org/and explore a little. =A0The NTP implementation can be > used to serve time if you need to, although I would use Windows as an > NTP server only as a last resort. > > NTP authentication is used to verify the identity of the servers you are > getting time from. =A0Authenticated packets are cryptographically signed > by the server. =A0If you need to be able to prove that your time is > traceable to some particular server, you would use authentication to do s= o. We had to install the windows pseudo-ntp service to support some voip phone software that only ran under windows. All the client peecees had to use the windows time service also to avoid other complications (ms is really good at the camels nose in the tent thing). Our VMS systems are so far all set up using external NTP servers as SERVER and setting each-other as 'PEER' entries in the config files. I can see them nattering at eachother about time a few times a day; mainly I think because the VAX is running TCPware while the Alphas and the itanic are running TCPIP services. No issues; the VMS systems ignore the windows network and vice versa. Rich ------------------------------ Date: Mon, 07 Jul 2008 13:35:48 -0400 From: JF Mezei Subject: Re: NTP on OpenVMS using TCPIP services Message-ID: <4872567a$0$31173$c3e8da3@news.astraweb.com> Would it be correct to state that for a computer to have a "peer" entry, it would also need to have a "server" entry ? aka: one source of reliable time, as well as peers with whom it can also adjust time ? Reason I ask is that without a server, a peer would have no idea of what stratum it was at (and thus assume 15) and then the other "real" systems would refuse to peer with it. Is this a correct understanding ? ------------------------------ Date: Mon, 7 Jul 2008 06:30:43 -0700 (PDT) From: AEF Subject: Re: Question about NTP.CONF master and local-master commands Message-ID: <017bd8f4-2407-430e-a4cc-f26040267217@l64g2000hse.googlegroups.com> On Jul 6, 7:44 pm, John Santos wrote: > In article <3ec340fb-9aad-4166-800b- > 6eb395883...@z66g2000hsc.googlegroups.com>, spamsink2...@yahoo.com > says... > > On Jul 3, 10:37 pm, John Santos wrote: > > > AEF wrote: [...] > > > Can you explain the point of the peer command? I still don't get that. > > I think your later questions about peers stem from this, so if I > explain it adequately, I won't have to answer them :-) > > Peers compare their clocks and average them. This gets a more > accurate time and converges on an accurate time more quickly > than a single client trying to sync with a server. The farther > away the server is (in hops, latency, etc., rather than in > pure physical distance, though of course physical distance > matters), the more inaccurate the clock will be. NTP attempts > to compensate for delays and variations in the round-trip time > between the clients and the servers, but on the Internet, strange > things can happen (dropped packets, routes changing due to circuits > going up an down or due to congestion, etc.) A bunch of peers at > one site can compare their clocks and average them. They can > also compare the round-trip times to the server(s) and get a > better idea of how to compensate. > > If the link to the remote server goes down, the local servers, > by peering, can keep time for the local network much more > accurately than a single server could. They can compensate for > inaccurate hardware clocks, missed interrupts etc. (These things > are unlikely to affect all the local servers identically, so if > two of them notice the third is out of whack, they'll all set their > times to most closely match the 2 still in sync, and the odds are > it it will be a more accurate time.) > > I'm not sure you actually want to use local-master on any of the > local servers unless you *know* that particular server has an > extremely accurate clock (like it's being set by an atomic clock > or radio time signal, rather than just by counting cycles of a > typical PC-grade clock chip, which is what most Alphas, Itaniums, > and "recent" VAXes use. I think you are better off just declaring > a bunch (3 or so) of them as peers, and letting them average > their clocks. When the link to the remote master is up, all the > local servers will sync off it anyway, so it doesn't matter if > they are local-masters or not. It's only when they've lost > contact that it matters. Well, if the remote server goes down, and if one of them is synching up to some (well, it's got to be some other) external NTP server, then what's the point? I'd just have all 3 of them synched to it anyway. > [...] > > But why do I need the peer commands as opposed to server commands? > > > [...] > > If the server is down, the peers will sync with each other. If any of > them had previously synced with the server (before it went down), > they'll collectively keep better time until the server comes back. I tried setting up two test servers to peer each other. Just one line each in their respective NPT.CONF files: peer and nothing useful happened as far as I could tell. Perhaps I should have waited a day or two to see if they stayed synched up. Here's what happened: 3 Jul 18:23:46 selected new sync source 10.1.10.24, now at stratum 3 NODE15$ type ntp.conf peer NODE08 slewalways NODE15$ @restart ntp %RUN-S-PROC_ID, identification of created process is 000003EA NODE15$ %%%%%%%%%%% OPCOM 5-JUL-2008 20:10:05.64 %%%%%%%%%%% Message from user SYSTEM on NODE15 %TCPWARE_NTP-I-ACQUIRED, acquired peer 10.1.10.181 NODE15$ type ntpserver.log; 5 Jul 20:09:33 NTPD started 5 Jul 20:10:05 acquired peer 10.1.10.181 NODE15$ %%%%%%%%%%% OPCOM 5-JUL-2008 20:18:37.60 %%%%%%%%%%% Message from user SYSTEM on NODE15 %TCPWARE_NTP-I-LOSTCONTACT, lost contact with peer 10.1.10.181 On the other node: NODE08$ TYPE NTPSERVER.LOG 5 Jul 20:10:20 NTPD started NODE08$ TYPE NTPSERVER.LOG 5 Jul 20:10:20 NTPD started Therefore, I thought I needed the local-master commands. > > > The 3 NYC server VAXes would all have > > > > server NYC-NTP-SERVER > > > peer NYCVAX2 > > > peer NYCVAX3 > > > > (or NYCVAX1 & NYCVAX3 for NYCVAX2, or NYCVAX1 and NYCVAX2 for > > > NYCVAX3) > > > > The 3 London server VAXes would have > > > > server NYCVAX1 > > > server NYCVAX2 > > > server NYCVAX3 > > > peer LondonVAX2 > > > peer LondonVAX3 > > > > (substituting appropriately for LondonVAX2 and 3.) > > > Looks fine, but I still don't see why you need peer instead of server > > or why it's better. Can you please explain it? > > What do you mean "instead of"? Do you want to tell system A that it's > server is system B, and tell system B its server is system A? That > makes no sense to me, and I think would keep the systems from ever > syncing their clocks. I'd chain them, I guess: A --> B --> C. > > Is your question "why have peers at all?" or is it "Why use the keyword > peer instead of server for the other servers in the same LAN?" I think The former, but I understand "peers" a lot better now. > I explained why to have peers above. Why to treat the NYC servers as > servers and the other London ones as peers, is the NYC servers are > "closer" to the official NTP server (which is presumably either syncing > with a more accurate clock on the Internet, or getting it's time from > some other, accurate source, such as a WWV receiver). You could ADD > the NTP server (which I called NYC-NTP-SERVER above) as a 4th NTP server > in the London configs, but once the NYC VAX servers have synced, they > would be just as good, and it's considered bad manners to bother the > higher up servers excessively. (That's why you don't just put > "server NYC-NTP-SERVER" as the entire ntp.conf file on *all* the VAXes. > Doing it heirarchically drastically reduces the network traffic on the > WAN links and the load on the higher stratum servers, while not > affecting accuracy very much. I thought the NTP protocal was a very small load. I never see anything significant going on. > > > Also, in the example in the TCPware Mgmt. manual, they have peer > > commands that "peer" with themselves! Example: > > > ; NTP configuration on 192.168.67.3 > > local-master 12 > > server 192.168.67.1 > > server 192.168.34.1 > > server 192.168.34.2 > > peer 192.168.67.3 > > > What's the point of that, or is it a typo on TCPware's part? > > Maybe so you can use the same ntp.conf on all the nodes. I didn't > know this worked, if it does, it would reduce management headaches > since you would only have to maintain 2 or 3 different NTP.CONF > files instead of a different one for each server. (One for all > clients (or one all clients in each area), one for all local servers, > and maybe a global one for higher stratum servers.) In your case, > you could have 4 distinct NTP.CONF's (NYC clients, London clients, > NYC servers and London servers) vs. 8 NTP.CONFs (NYC clients, > London clients, and one for each of your 6 servers.) Well, they do suggest a different one for each of the servers in the work area while the three in the server commands above are in the "climate-controlled room". I was hoping the online manual would have the example in it, but it doesn't. So here goes some typing: In the text and diagram we find that the first three servers are in the climate-controlled room with 192.168.67.1 on a radio link and the x, y, z, ... are "on the floor". =============================================================================== ; NTP Confuguration on 192.168.67.1 master-clock 1 =============================================================================== =============================================================================== ; NTP Config on 192.168.67.2 local-master 10 server 192.168.67.1 server 192.168.34.1 server 192.168.34.2 peer 192.168.67.2 =============================================================================== ; NTP Config on 192.168.67.3 local-master 12 server 192.168.67.1 server 192.168.34.1 server 192.168.34.2 peer 192.168.67.3 =============================================================================== ; NTP Config for Computer RoomHost 192.168.67.x server 192.168.67.1 server 192.168.67.2 server 192.168.67.3 peer 192.168.67.y peer 192.168.67.z . . . =============================================================================== Comments? > > > All the other NYC VAXes would have: > > > > server NYCVAX1 > > > server NYCVAX2 > > > server NYCVAX3 > > > > and all the other London VAXes would have: > > > > server LondonVAX1 > > > server LondonVAX2 > > > server LondonVAX3 > > > > in there respective NTP.CONF files. > > > Yes, this is what I was going to do for them. > > > But... would it make sense to add "server NYC-NTP-SERVER" to all the > > VAX systems in case the three local-masters in NYC go down or are > > taken down, or am I being to paranoid, or is that a bad idea for some > > other reason? Or should I just add "peer > this city" as in the example in the TCPware manual? > > > BTW, my motivation is to have all the times correct based on UTC, and > > if I lose connection to the data center's NTP server, at least have > > all the VAX systems synchronized to each other. > > > Thanks again. > > NTP *always* works on UTC. For VMS systems which are usually/often > based on the local time zone, the NTP client has to convert the UTC > time to local time before setting the clock, and the NTP server has > to convert the local clock time to UTC before supplying it to clients. I didn't mean to imply that it didn't. Ideally I want all the VAX systems to be UTC or my designated number of hours away from UTC as some servers are set to UTC, some to UTC+2, and some to ET. Failing that, I want them to at least be synchronized together. If they drift a few seconds from being based on UTC when the company NTP server is down for a few days it's no big deal. > > It doesn't matter if your systems are all running on UTC or if some > are on London time and others are on NYC (Eastern US) time, or anything > else, TCPware and/or HP TCP/IP's NTP software takes care of this. Yes, I know. > > I assume windows NTP clients do the same. Most (all?) Unix systems > keep their system clock in UTC, so it isn't an issue for them. Thanks again for your help. > > > -- > > > John Santos > > > Evans Griffiths & Hart, Inc. > > > 781-861-0670 ext 539 > > > AEF > > -- > John AEF ------------------------------ Date: Mon, 7 Jul 2008 02:38:50 -0700 (PDT) From: IanMiller Subject: Re: Show of support for Distributed NetBeans Message-ID: On Jul 6, 10:48=A0pm, "Richard Maher" wrote: > Hi, > > I'm not trying to stir up a NetBeans vs Eclipse discussion here, but I ha= ve > just read this: -http://www.openvms.org/stories.php?story=3D08/07/04/0015= 580 > and was wondering if anyone had tried it or had any opinions about how th= e > two IDEs compare and contrast on VMS. I guess one's free and the other > costs, and one runs on VMS and the other is "distributed"? Personally, I'= m > happy with TPU and would prefer more substantial infrastructure software = on > VMS (such as that XHR$ library) but I am interested in what other's have > tried or are looking for in an IDE on VMS. > > NetBeans would seem to be a better fit for GlassFish (when the IMM team c= ome > out of the closet with it) but, apparently, "Customers can increase > productivity with HP OpenVMS and eCube's NXTware Eclipse," says Ann McQua= id. > Can't say fairer than that eh? > > Of course, given the current levels of VMS application "development" goin= g > on outside of Ann-world one wonders why we need a new DE at all, let alon= e > an Integrated one :-( > > Regards Richard Maher > > "Marty Kuhrt" wrote in message > > news:_ZmdnYyE-sDCsOzVnZ2dnUVZ_hWdnZ2d@speakeasy.net... > > > IanMiller wrote: > > > On Jun 17, 12:08 pm, issinoho wrote: > > >> Chaps, > > > >> Just thought I'd show a bit of support for the Distributed NetBeans > > >> product. Not sure how many of you are using it or have tried it but = it > > >> really is a terrific addition to the development options on OpenVMS. > > > >> I recently finished porting a rather large commercial control system > > >> from VAX C to I64 and did it the old-fashioned character-cell way > > >> which although perfectly acceptable felt a bit archaic in this day a= nd > > >> age. > > > >> I installed and ran NetBeans and it handled the entire project > > >> flawlessly; in fact, I was editing and compiling the code base from > > >> within a modern Windows IDE back onto the VMS server. From a standin= g > > >> start this took all of about 3 hours and involved C, MMS and FMS. > > > >> So, a slap on the back to the team involved and thanks for this. > > > > I think it's an interesting thing but it was in beta for so long that > > > NetBeans has moved on to V6. I hope they get the next version out the > > > door quicker. > > > I'd also like to see more documentation on how to debug the IDE Server > > and associated stuff on the VMS side. =A0They have some examples in the > > online docs on how to set stuff up, but only if nothing "bad" happens. > > I've been trying to get it to work on my development system without muc= h > > luck. > > > Using an FTP file system project I cannot seem to get the remote machin= e > > to sync. =A0The IDE server is running and it seems to be responding to = the > > =A0 diagnostics and compile requests. =A0I can manually ftp from the cl= ient > > to the server without problem, but the ide client doesn't seem to be > > able to do it. =A0If the files aren't sync'd then the compile just says > > "FNF". Nice to see someone reads the news :-) ------------------------------ Date: Mon, 7 Jul 2008 05:01:39 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: VMS SAN Primer Message-ID: <4e37b5ad-4c44-4e74-9a21-40421b230608@s50g2000hsb.googlegroups.com> On 5 Jul, 10:00, JF Mezei wrote: > > Consider the case where you have some SAN that supports VMS, Unix, *EVIL > WINDOWS* , OS-X and Linux. > > You must dig into the SAN configutation to ensure that Windows doesn't > see the VMS disk and that it cannot possibly ever even think about > writing its "signature" on your VMS drives. > Does that infer that there's a Non-Evil Windows??? :o) Selective presentation keeps different boxes from seeing each others' disks. Different zones keeps the Windows boxes from seeing the VMS disks and vice versa. It's important to remember too that not all storage arrays are equal in the HP range. The MSA1000 and MSA1500 didn't support VMS and anything on the same storage array. MSA2000s are not supported on VMS *yet*. EVAs can do VMS and Windows on the same storage array, though you have to split up what can see which. Steve ------------------------------ Date: Mon, 7 Jul 2008 05:07:51 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: VMS SAN Primer Message-ID: <0f8f3cdd-ec96-4938-8a85-9e6b8c6bff20@26g2000hsk.googlegroups.com> On 6 Jul, 15:49, IanMiller wrote: > On Jul 6, 3:31=A0am, Michael Austin wrote: > > > > > > > David J Dachtera wrote: > > > JF Mezei wrote: > > >> Paul Lentz wrote: > > > >>> I sorta knew there couldn't be much difference... > > >> But wait a minute, don't SANs use very different terminology. They t= alk > > >> about switches, fabric etc . > > > > True. However, the terminolgy has become very confused (confusing). > > > > When folks say "SAN", they really mean "storage array". > > > > When folks say "fibre channel", they really mean "storage area networ= k" > > > (SAN - as in the interconnecting infrastructure). > > > > ...and "a separate 'fabric'" equates roughly to a VSAN (Virtual Stora= ge > > > Area Network), corrolary to a VLAN. VSANs taking "zoning" to another > > > level, as it were. On CI or over Ethernet, the VMS equivalent would b= e > > > the cluster id. number. > > > >> And don't SANs have many many capabilities such as RAID, abilities t= o > > >> comvine physical disks into a single drive, or partition a single dr= ive > > >> into multiple drives ? > > > > Yes. Think: "HSG" or SWXCR. > > > >> Do SANs provide any concept of shared locking ? > > > > Does a CI provide such a concept? ...shared SCSI...? > > > >> Can a node request that > > >> a block on a drive be locked for writes by other nodes ? > > > > Within the confines of an operating "domain" such as a VMS cluster, > > > certainly. However, it requires a distributed lock manager. > > > >> Or is it pretty much a total free for all with SANs just blindly > > >> executing requests on any drive from any node ? > > > > In so far as "drive" and "node" are virtual concepts, yes. However, > > > there is no "magic" which enables sharing. Read on... > > > >> (I would assume that SANs would have ability to provide "views" whic= h > > >> means that a particular node woudl have a defined list of disks it c= an > > >> access ? > > > > Yes and no. "LUNs" (remember: FC is just a way to carry the SCSI > > > protocol over a light "beam") are "mapped" to specific fibre adapters > > > ("FA" for short, in the parlance) on the storage array, and "masked" = for > > > access by specifc HBAs (by WWID). > > > >> Or can it go and peak at disk drives that have been assigned to > > >> other nodes ? > > > > Zoning, mapping and masking restrict "visibility" between specific HB= As > > > and LUNs. > > > >> Seems to me that there would be a large number of management issues = to > > >> deal with that would not be needed in case of a VMS cluster. A VMS > > >> cluster offers a single security concept, shared locking etc. When y= ou > > >> have different seperate nodes accesing drives in a SAN, those are no > > >> longer applicable. > > > > Well, you're confusing SANs with MSCP-served storage. > > > > The best way to think of a storage array is as if a tremendously > > > talented SWXCR were housed in a rack/frame with fairly large number o= f > > > physical drives. The physical drives are grouped together by the arra= y > > > manager (a person, that is) into virtual devices. Think: RAIDsets, > > > mirrored RAIDsets (5+1 for example) and mirrored stripe sets. Quite > > > literally, a superset of what's available on an HSJ, HSZ or HSG. Thos= e > > > virtual devices are thent presented to specific hosts via zoning, > > > mapping and masking. > > > > ...however, it is just storage. A LUN. It's still up to the host > > > operating environment to manage that storage. Such management is NOT = the > > > array's job in a FCSF/SAN anymore than it would be in an HSJ on a > > > CI-based storage array. The array simply presents storage. Each LUN > > > appears to the host as if it were a separate "SCSI" device. A "LUN" m= ay > > > occupy a portion of each disk in a disk group (in EVA parlance), for > > > example. VMS, Windows, UX, AIX, etc. only "sees" a SCSI device over F= C > > > ($1$DGAnnnnn:), while the actual storage presented may consist of a > > > RAIDset or a stripeset, with or without mirroring (on the array, not > > > HBVS). > > > > There's no "magic" in a FCSF SAN which can allow incompatible operati= ng > > > environments to either co-exist or share storage devices. The > > > limitations of each operating environment transcend the storage domai= n, > > > regardless. > > > > Clear as mud, eh? > > > > Thought so... > > > > D.J.D. > > > I took a job a few years ago doing Sysadmin on OpenVMS on SAN. =A0Looki= ng > > at the SAN - it is essentially a smart Star-coupler. =A0It directs traf= fic > > to only those arrays and "devices (aka LUN)" you have specified. Once > > the pointers are set - it is very very easy... > > > The SAN Switches make up a fabric - which is nothing more than a fiber > > network. =A0Your HBA's can attach to the same fabric - or redundant > > fabrics. Blue/Red for example. > > > This is an over-simplification, but hopefully you get the idea... > > Read the presentation on Data networking and Storage Networking on the > XDelta site > > http://www.hpug.xdelta.co.uk/- Hide quoted text - > > - Show quoted text - That doesn't make any note of any of the MSA family of storage arrays. Most of the VMS installations that I've seen/been involved with use them rather than EVAs, but then maybe I deal with smaller clients than XDelta? ------------------------------ Date: Mon, 07 Jul 2008 08:21:31 -0400 From: Pete Subject: Re: VMS SAN Primer Message-ID: <4e2474hp89spj3qq23j5om00bim1ormcmb@4ax.com> On Fri, 4 Jul 2008 09:54:36 +0100, "Richard Brodie" wrote: For SAN specific information take a look at the HP's San design guide. http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual&locale=en_US&docIndexId=179911&taskId=101&prodTypeId=12169&prodSeriesId=406734 Watch for wrap. Pete ------------------------------ Date: Mon, 07 Jul 2008 09:49:05 -0400 From: JF Mezei Subject: Re: VMS SAN Primer Message-ID: <48721ed4$0$2063$c3e8da3@news.astraweb.com> etmsreec@yahoo.co.uk wrote: > disks and vice versa. It's important to remember too that not all > storage arrays are equal in the HP range. The MSA1000 and MSA1500 > didn't support VMS and anything on the same storage array. MSA2000s > are not supported on VMS *yet*. If storage arrays present SCSI disks to VMS, why would one an array need to be aware of a specific OS ? Or why would VMS need to have code specific to an array if the array prosents standard SCSI interface on standard hardware for communications ? (asking to learn, not to question the statements). ------------------------------ Date: Mon, 7 Jul 2008 08:19:52 -0700 (PDT) From: IanMiller Subject: Re: VMS SAN Primer Message-ID: <09140bcd-e17d-41d0-9af4-faae493b7ca9@c65g2000hsa.googlegroups.com> On Jul 7, 1:07=A0pm, etmsr...@yahoo.co.uk wrote: > On 6 Jul, 15:49, IanMiller wrote: > > > > > On Jul 6, 3:31=A0am, Michael Austin wrote: > > > > David J Dachtera wrote: > > > > JF Mezei wrote: > > > >> Paul Lentz wrote: > > > > >>> I sorta knew there couldn't be much difference... > > > >> But wait a minute, don't SANs use very different terminology. They= talk > > > >> about switches, fabric etc . > > > > > True. However, the terminolgy has become very confused (confusing). > > > > > When folks say "SAN", they really mean "storage array". > > > > > When folks say "fibre channel", they really mean "storage area netw= ork" > > > > (SAN - as in the interconnecting infrastructure). > > > > > ...and "a separate 'fabric'" equates roughly to a VSAN (Virtual Sto= rage > > > > Area Network), corrolary to a VLAN. VSANs taking "zoning" to anothe= r > > > > level, as it were. On CI or over Ethernet, the VMS equivalent would= be > > > > the cluster id. number. > > > > >> And don't SANs have many many capabilities such as RAID, abilities= to > > > >> comvine physical disks into a single drive, or partition a single = drive > > > >> into multiple drives ? > > > > > Yes. Think: "HSG" or SWXCR. > > > > >> Do SANs provide any concept of shared locking ? > > > > > Does a CI provide such a concept? ...shared SCSI...? > > > > >> Can a node request that > > > >> a block on a drive be locked for writes by other nodes ? > > > > > Within the confines of an operating "domain" such as a VMS cluster, > > > > certainly. However, it requires a distributed lock manager. > > > > >> Or is it pretty much a total free for all with SANs just blindly > > > >> executing requests on any drive from any node ? > > > > > In so far as "drive" and "node" are virtual concepts, yes. However, > > > > there is no "magic" which enables sharing. Read on... > > > > >> (I would assume that SANs would have ability to provide "views" wh= ich > > > >> means that a particular node woudl have a defined list of disks it= can > > > >> access ? > > > > > Yes and no. "LUNs" (remember: FC is just a way to carry the SCSI > > > > protocol over a light "beam") are "mapped" to specific fibre adapte= rs > > > > ("FA" for short, in the parlance) on the storage array, and "masked= " for > > > > access by specifc HBAs (by WWID). > > > > >> Or can it go and peak at disk drives that have been assigned to > > > >> other nodes ? > > > > > Zoning, mapping and masking restrict "visibility" between specific = HBAs > > > > and LUNs. > > > > >> Seems to me that there would be a large number of management issue= s to > > > >> deal with that would not be needed in case of a VMS cluster. A VMS > > > >> cluster offers a single security concept, shared locking etc. When= you > > > >> have different seperate nodes accesing drives in a SAN, those are = no > > > >> longer applicable. > > > > > Well, you're confusing SANs with MSCP-served storage. > > > > > The best way to think of a storage array is as if a tremendously > > > > talented SWXCR were housed in a rack/frame with fairly large number= of > > > > physical drives. The physical drives are grouped together by the ar= ray > > > > manager (a person, that is) into virtual devices. Think: RAIDsets, > > > > mirrored RAIDsets (5+1 for example) and mirrored stripe sets. Quite > > > > literally, a superset of what's available on an HSJ, HSZ or HSG. Th= ose > > > > virtual devices are thent presented to specific hosts via zoning, > > > > mapping and masking. > > > > > ...however, it is just storage. A LUN. It's still up to the host > > > > operating environment to manage that storage. Such management is NO= T the > > > > array's job in a FCSF/SAN anymore than it would be in an HSJ on a > > > > CI-based storage array. The array simply presents storage. Each LUN > > > > appears to the host as if it were a separate "SCSI" device. A "LUN"= may > > > > occupy a portion of each disk in a disk group (in EVA parlance), fo= r > > > > example. VMS, Windows, UX, AIX, etc. only "sees" a SCSI device over= FC > > > > ($1$DGAnnnnn:), while the actual storage presented may consist of a > > > > RAIDset or a stripeset, with or without mirroring (on the array, no= t > > > > HBVS). > > > > > There's no "magic" in a FCSF SAN which can allow incompatible opera= ting > > > > environments to either co-exist or share storage devices. The > > > > limitations of each operating environment transcend the storage dom= ain, > > > > regardless. > > > > > Clear as mud, eh? > > > > > Thought so... > > > > > D.J.D. > > > > I took a job a few years ago doing Sysadmin on OpenVMS on SAN. =A0Loo= king > > > at the SAN - it is essentially a smart Star-coupler. =A0It directs tr= affic > > > to only those arrays and "devices (aka LUN)" you have specified. Once > > > the pointers are set - it is very very easy... > > > > The SAN Switches make up a fabric - which is nothing more than a fibe= r > > > network. =A0Your HBA's can attach to the same fabric - or redundant > > > fabrics. Blue/Red for example. > > > > This is an over-simplification, but hopefully you get the idea... > > > Read the presentation on Data networking and Storage Networking on the > > XDelta site > > >http://www.hpug.xdelta.co.uk/-Hide quoted text - > > > - Show quoted text - > > That doesn't make any note of any of the MSA family of storage > arrays. =A0Most of the VMS installations that I've seen/been involved > with use them rather than EVAs, but then maybe I deal with smaller > clients than XDelta? There are newer versions of presentations from xdelta. Do contact them and ask. ------------------------------ End of INFO-VAX 2008.377 ************************