iSCSI on the 104 is sutiable for light use. Configuring them correctly for the use case is also important. What are your LUNs used for?
I saw that article, yes. It's one of the ones that's not applicable. On the RN104/OS6 the configuration screen is different than the instructions there—it doesn't provide a field for an IP address.
So right off the bat I'm sent looking elsewhere. Trouble is, I'm not finding anything that quite matches my scenario—a non-networkable UPS attached to a ReadyNAS that needs to shut down AFTER the server.
Also, the shutdown configuration dialog on the NAS is based on percentage of power remaining—I need both shutdowns to be based on duration. Time, not capacity.
I'm using the LUNs for nightly backup storage only. Some of my VM OSs want to see a local drive for their backup targets—I can't do it with UNC paths.
If this was two ReadyNAS, I'd suggest setting a manual shutdown setting on the NAS accessing the UPS over the network. For instance, setting the shutdown threshold at 30%, but use automatic (or perhaps 10%) on the directly connected NAS.
If you could install NUT on the server, you could perhaps do the same.
Of course you'd need to test it. My usual suggestion is to connect the UPS power to a dummy load (not the actual devices). Then pull the plug, and see if you have enough margin on the two shutdowns.
If this was two ReadyNAS, I'd suggest setting a manual shutdown setting on the NAS accessing the UPS over the network. For instance, setting the shutdown threshold at 30%, but use automatic (or perhaps 10%) on the directly connected NAS.
I suppose I could live with percentage as the criteria, as long as the two are the same. But time on one and percentage on the other won't mix.
If you could install NUT on the server, you could perhaps do the same.
Sounds nice, but that's just it—how can the server talk to the UPS (again, the non-networked UPS) that's plugged into the NAS' USB port, especially since there's no way in the UI to specify an IP address?
Correct me if I'm mistaken, but that sounds like square one to me—getting the devices to talk to each other in the first place.
Of course you'd need to test it. My usual suggestion is to connect the UPS power to a dummy load (not the actual devices). Then pull the plug, and see if you have enough margin on the two shutdowns.
Not to be a thick-head, but if we don't test with the actual devices how can we get a correct test?
Research NUT (Network UPS Tools) - unless I'm very much mistaken you'll find it can be run as a server on the device which is directly connected to the UPS, and as a client on another device, which can then be configured to poll the NUT server on the first device.
As far as testing with a dummy load goes, it's common practice when testing autonomous shutdown to use a dummy load on the UPS with the devices power from the utility - you can then "pull the plug" to simulate an outage, and then watch to see if the devices shut down before the UPS does - if this test works, you can then repeat with the devices as the load.
The real solution to your situation, at least, to my way of thought, is to replace the UPS with one that does have a network interface - I dare say you'll find what you are attempting considerably easier - I run an older APC SmartUPS 1400, with an APC9617, and use that to shutdown a Windows 2008 server (running APC PowerChute) and a ReadyNAS102 - the shutdown settings can be tweaked to shut down the devices in whatever sequence you desire.
I also note that you mention HyperV & VMs - I've never used HyperV, but, if it's anything like VMWare, you'll need the UPS network monitoring to automatically shutdown the VMs before shutting down the host OS.
Research NUT (Network UPS Tools) - unless I'm very much mistaken you'll find it can be run as a server on the device which is directly connected to the UPS, and as a client on another device, which can then be configured to poll the NUT server on the first device.
Say, that sounds great! I'll look into that, thanks.
As far as testing with a dummy load goes, it's common practice when testing autonomous shutdown to use a dummy load on the UPS with the devices power from the utility - you can then "pull the plug" to simulate an outage, and then watch to see if the devices shut down before the UPS does - if this test works, you can then repeat with the devices as the load.
Ah. Gotcha. The difference is that the production devices aren't drawing from the UPS during the test. And as far as that goes, I could power just about anything from the UPS during the test—some sort of high-load device, for example. Makes sense now, thanks.
The real solution to your situation, at least, to my way of thought, is to replace the UPS with one that does have a network interface
I'd love to. I'd also love to have the $700 that APC wants to charge me for replacing my current setup with the correct parts I'd need. ($225 loss on the new unit I just bought, plus $470 for the add-in network card.) So I think I'm going to wait a bit on that one 😉
I also note that you mention HyperV & VMs - I've never used HyperV, but, if it's anything like VMWare, you'll need the UPS network monitoring to automatically shutdown the VMs before shutting down the host OS.
A Hyper-V host pauses its guest VMs during a graceful shutdown (at least the latest version does). I've never used VMWare, but I can't imagine it not doing something similar.
So I'm off to the client/server tests—thank you! (Found a link here.)
iSCSI on the 104 is sutiable for light use. Configuring them correctly for the use case is also important. What are your LUNs used for?
I'm using the LUNs for nightly backup storage only. Some of my VM OSs want to see a local drive for their backup targets—I can't do it with UNC paths.
Hi mdgm
I'm interested in your assessment on my configuration, with regard to LUNs on the RN104. As you say, the 104 isn't built for heavy iSCSI use—but I'm only using it to store nightly backups. It's been up and running for about a month and so far it hasn't given me trouble.
