Experts on SoIP, iSCSI, NT mirrored drives
Jon Toigo and Steven Toole
Editor's Note: Following are a few, selected answers from two of searchStorage's own storage management experts, Jon William Toigo and Steven Toole. Toigo is managing partner with Toigo Productions and brings with him over 20 years of experience in IT and storage. Toole is vice president of marketing for WQuinn and has years of experience with Windows NT/2000 servers.
Q: Would you please give your opinion on storage over IP, and why you think it will or won't work? Additionally, would you mind sharing your thoughts about the best way to do TCP/IP offload, specifically for network storage applications?
A: (Toigo) I believe that the very existence of the protocol demonstrates that, with respect to Fibre Channel SANs, the "emperor has no clothes." That is to say, switch interoperability issues and high deployment costs impede the deployment of enterprise wide (and extra enterprise) FC SAN solutions. Companies must turn instead to Cisco Systems, Nishan and other Storage over IP vendors for a kludge that will enable the cobbling together of little FC SAN islands using GigE/IP nets. That's just bad architecture.
Will it work? Sure it will. But I firmly believe that as iSCSI matures, FC SANs generally will be relegated to a niche.
Don't know how much space I have for your second question, but I'll give it a try. I had a chat with my fellow Floridians at DataCore Software and discussed your question. Here was their view:
"On IP offload, the software approach should better leverage existing hardware, so it's likely to have early traction. Once mature, and the many legacy SCSI issues have been addressed, then the ASIC route will make more sense. As with many of these projections, commercial reasons rather than technical ones will drive the adoption of SCSI over IP."
I agree with DataCore up to a point. Frankly, however, I see HBAs enabled with TCP stack offload chips already being prepared by numerous manufacturers. This is old technology really. I remember writing white papers for Cisco around a similar approach used to offload IBM mainframe IP stack processing (the mainframe IP stack software was terrible in those days) to a router blade in the 1992 timeframe. Doing stack offload in silicon is much more efficient and less prone to failure than software approaches.
Q. We are currently running Windows NT 4 SP5 on a Compaq Proliant 3000 with mirrored 4gb drives. Using NT to mirror the drives, we were going to test pulling the primary out and boot from the second. To our surprise, the machine would not boot. We tried switching the boot files (boot.ini) to reflect the change but no luck.
A. (Toole) You cannot boot from the mirrored drive, you must create a boot floppy with NTLDR; NTDETECT.COM; NTBOOTDD.SYS and BOOT.INI. You need to modify the BOOT.INI to point to the partition number of the other mirrored volume:
Once you have restarted NT, you must use Fault Tolerance>Break Mirror. You then need to reestablish the mirror with another free partition.
* View Jon's recent Live Expert Q&A online event, "What to do when things fall apart: strategies to minimize and cope with downtime."
* Find out what Jon Toigo had to say about the following questions:
*Are individual vendors providing SAN management using CIM or JIRO tools? What's the best strategy to design a SAN management tool for a vendor specific H/W such as a switch?https://searchstorage.techtarget.com/answer/SAN-management-tools.
* How is SAN storage dynamically configured in a Microsoft environment and how does the OS attach the storage once it is zoned and reachable by that MS server? https://searchstorage.techtarget.com/answer/SAN-storage-configured-and-attached.
* And check out Steven Toole's answer to this recent user-submitted question:
* Where should you start when researching storage management software? The hardware vendors themselves or do you think outside ISV solutions are worth a look? https://searchstorage.techtarget.com/answer/Researching-storage-management.
* View questions and answers from Jon, Steven and other of our experts.