----------------------------------------------------------------------- NOV-MOAB.DOC -- 19980114 -- Email thread on NW's "Next Gen" IP-Only NOS ----------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Thu, 20 Nov 1997 10:27:04 -0600 From: Joe Doupnik Subject: Re: MOAB >Does anyone have any information sites about MOAB? I have seen very >little about it on Novell's site. Thanks. ------- Please note that Moab is now available as a public beta, with all the joys that go with betas. Please see Novell's web page for details and request form. Just a word of caution. Beta software should be tested on non- production machinery, and when NDS is involved it is often wise to use a test tree. Moab runs, I set up such a server last summer as a native IP device. Joe D. --------- Date: Thu, 20 Nov 1997 17:35:07 +0000 From: Richard Letts Subject: Re: MOAB Look in the intranetware section on http://support.novell.com/beta/public/ or http://support.novell.com/beta/public/intranetware/moab/ ------------------------------ Date: Fri, 5 Dec 1997 15:39:20 -0600 From: Joe Doupnik Subject: Re: MOAB, NLMs, and HARDWARE >Questions about Moab that I was hoping someone could shed some light on. > >Does Moab have increased hardware requirements? Our Compaq P100 server >with 144MB RAMdoes a great job for ~200 users running INW 4.11. Should >we consider a faster machine? > >How will existing NLMs run with the new memory protection and virtual >memory features? -------- It's requirements to-date are basically those of NW 4.1x. Clearly your server's memory is totally dominated by non-o/s issues and thus one cannot address them without testing. As to "How will existing NLMs run", that depends on the NLM and the various APIs in use and so on. Specifics need to be addressed, and you won't be able to do that job completely until NetWare 5 is released. Generally things should run, but that is a vague generality. You can obtain Moab beta-1 by visiting Novell's web site and filling out a request form. This is hardly like the release product in that much more work will be added in later betas. Please underscore the previous sentence. Joe D. ------------------------------ Date: Tue, 16 Dec 1997 19:19:41 +0200 From: Mike Glassman - Admin Subject: SFT III vs. Vinca >I'd like to hear some pros and cons from people who've actually used >these products? I have a client in the medical field who wants >SFT III - I've never done one. SFT III. Some minor points to remember when considering the use of SFT in a Netware environment are... 1. With the soon to be availability of Moab, SFT III will no longer be developed. This of course means that new patches etc, might cease to support SFT III, and this is a very big issue. 2. SFT III needs two identical hardwares, from the smallest screw to the largest disk and the last bit of memory. Vinca does not and can use any two machines so long as the disks are similar in size. 3. SFT III in oposition to all the other such products on the market, mirrors disks AND memory. This has definite advantages, and very serious disadvantages, the main being, that if you have memory corruption on one server, it is also going to be duplicated to your mirrored server. This demands you bring down the system fully before it will clear memory. Many people seem to think it is enough to bring one down, but trust me, it isn't. 4. If you are considering SFT III, remember that your network NIC's are NOT allowed to work faster than your SFT connector NIC's. In most cases, this means you cannot use any NIC that is faster than 100MB or your SFT will simply fail. 5. SFT is absolutely fantastic during mirrored servers crashes, allowing you to take down either machine..or in case of a crash, bring one back up without ANY lag at all on the users part. None of the NT based systems can say the same, including Vinca. Of course, the longer the lag between a data commit to actual commit, can sometimes mean a corrupted file or database. FTP handles this exceptionaly well. At my site, we currently have 9 SFT III systems, and we are installing 2 VINCA systems at a new site. this choice is not because we do not want to use SFT III anymore, but simply because we need NT as an SQL machine and Vinca provides the closest solution to SFT. My final view....SFT III with thoughts to Clustering in the future. As for that, External RAID disks on each server will allow for a much better upgrade path towards Clustering whenever you decide, and if you decide to move. --------- Date: Tue, 16 Dec 1997 11:31:02 -0600 From: Dave Kearns Subject: Re: SFT III vs. Vinca >1. With the soon to be availability of Moab, SFT III will no longer be >developed. This of course means that new patches etc, might cease to >support SFT III, and this is a very big issue. Not quite true. While NetWare 5 (aka Moab) will not have an SFT III option, the marketing info for Orion (the code name for cluster services based on Wolf Mountain, which will run only on NetWare 5) indicate that NetWare 4 and SFT III will continue to be available. Since we've just seen NetWare 3.12 updated, I wouldn't write off SFT III on NetWare 4.11 just yet. --------- Date: Tue, 16 Dec 1997 16:16:29 -0500 From: Jim Ryan Subject: Re: NOVELL Digest - 16 Dec 1997 - Special issue Re: #5. This is not true. Our Fault Tolerant NT server will do this. WWW.MOD.COM --------- Date: Tue, 16 Dec 1997 13:10:00 -0400 From: "BURTT, PETER (AEL)" Subject: Re: SFT III vs. Vinca I've been running SFTIII for over a year now, and I'll give you the same advice I gave a colleague a couple of weeks back. SFT III is complicated, and not well documented (in my opinion.) There were some very good TIDs on the Novell web site, Here's what I consider to be important SFTIII tips... Some are from experience, some are from reading. - make sure that the hardware in the two servers is identical, i.e. processor, motherboard, RAM, hard drive controller, etc. - some people set up the hard drives in a RAID configuration on an SFTIII box, but you're allready mirroring drives across the two servers, so why waste the storage and lose speed? I've got my discs striped into a single, non-redundant system drive, so that large reads are spread across multiple discs. Nice and fast! - try and leave yourself at least a couple of weeks to play with SFTIII and get comfortable with it before you put mission-critical stuff on it. It's kind of strange to work with, most things are just like normal NetWare, and then you find something that requires a different approach. It's better to find that sort of thing on a test server, I played for a month before I dared convert AEL_HEAD3 into the main file server. Here are some of the shortcomings of SFTIII. - SFTIII is designed to protect against hardware failures. If a software problem occurs, then it happens in real time on both servers, and they both crash in real time. - SFTIII doesn't allow you get a lot of the stats in MONITOR.NLM like LAN driver stats, process utilization stats, process memory stats, etc etc. It makes troubleshooting lots of fun. - don't even try to set up backup hardware on an SFTIII server, use a normal NetWare server for that. We kept the DAT changer on our old Dell 486/66 (AEL_HEAD1) and it does our backup. - setting up TCP/IP on SFTIII is way more complicated then you would think, so we didn't bother. We left TCP/IP and NetPrint on AEL_HEAD1. Not that I don't like SFTIII, but you should be aware of what you're getting into... ------------------------------ Date: Wed, 14 Jan 1998 13:38:47 +0200 From: Mike Glassman - Admin Subject: Re: Moab Installation Requirements The basic requirements will be the same as IW if not slightly less due to the fact that there will be, or it was stated that there will be NSS (Netware Storage Services) as an integral part of the MOAB makeup. This of course allows for less memory to be used for FAT's etc. As well as the way NSS mounts disks, you should be able to mount much larger disk spaces in much much less memory. ------------------------------