Re: CARP Cold Spare
Unsure what the power draw is on these guys yet, they just got them. They have redundant 450W Platinum power supplies. The "new" servers are completely overkill for the application, but this is a work-with-what's-available situation. They got these free from a friend and don't want to spend on new hardware, otherwise I'd just get them something "smaller" and supremely efficient. We already have redundant UPS's. With the 3 servers previously (main VM servers and 1 now-dead firewall) attached to battery-backed power, we were getting roughly 3.5 hours of runtime before UPS drop. Sometimes minutes can matter with these blackouts. I also want that with the one machine not running, it's not incurring any wear or tear just for the sake of hot failover. I've got no talent on site, so in the event of a hardware or file system failure, It's an extremely tedious experience for me to walk someone there through swapping hardware, wiring, or reinstalling an operating system. So, I'm looking for that turn-this-one-off-and-this-one-on recovery option, without the need to fiddle with any hardware. If this works the way I want, the only single point of failure will be their cable modem, and Comcast can handle replacing that. Option B is to just have identical configurations and have them need to swap the network wiring as part of the failover. Will still prevent the days of downtime we're incurring now due to this failure, but not as simple for them, if the CARP solution is solid. > On Sep 25, 2021, at 10:25 AM, leonard wrote: > > > What is the power draw? I use a 1500 VA apc backups with 6 outlets on ups and > 5 on surge protection. As long as your total draw is less than 1200 VA, for < > $200 canadian you have a cheap simple solution. Just put on on the ups side > and the other on the surge suppressor side. Or buy 2. > > > > leonard@on the road > > > Original message > From: Don Tek > Date: 2021-09-25 11:40 (GMT-05:00) > To: jslee > Cc: misc@openbsd.org > Subject: Re: CARP Cold Spare > > I'm not sure why the hardware matters, but the two machines are a couple HP > 1U Gen 8 Xeon servers. Suffice to say, they are identical and have supported > hardware configurations for OpenBSD. > > Of course I _could_ run one off direct power, but it would be a terrible > idea. The location is notorious for power surges, blips that are enough to > reboot servers and several-second brown-outs. So, not connected to the UPS > is just asking for damages. > > They experience multi-hour blackouts what seems like once a month; this is > where the desire to limit the draw on the UPS's comes from. To ensure we > make it through without having to shut down. > > Remote access is of primary concern, both for me for support, since I'm > geographically far enough away that being on-site is not feasible, and to the > customer, who just wants to stay home and work on systems in the office. > > Configurations on the servers almost never change (simple firwall), so > besides having to run a quick syspatch and reboot once at time of failover, I > don't see maintenance being so bad. I keep config files backed-up otherwise > centrally for quick restore to the running box as well. > > My primary concern here is if CARP / pfsync will have issues with the one > machine being down a majority of the time. Based on the FAQ, I think not, > but have no practical experience. > > > On Sep 25, 2021, at 3:00 AM, jslee wrote: > > > > Hi, > > > > You haven’t said anything about your hardware platform, but could you run > > one of them on non-UPS power? Then you’d still have one online when (*not* > > if) the UPS fails, and also they’ll both normally be online for > > maintenance, syspatch, config changes etc > > > > I do recall installing a pair of identical servers at the same time and > > having them both fail a year later within an hour of each other, both with > > seized CPU fans, so I am somewhat sympathetic to your idea. But I think the > > practical cost of maintenance may be rather high > > > > John > > > > > >> On Sat, 25 Sep 2021, at 08:13, Don Tek wrote: > >> Would there be any ‘problem’ with configuring a 2-machine CARP setup > >> and then just keeping one machine powered-off until needed? > >> > >> I realize this defeats live failover, but this is not a requirement for > >> my customer. > >> > >> I just want them to be able to, in the event of a primary machine > >> failure, power-on the secondary and have it take over. Logic here is > >> to otherwise not have the secondary sucking power off the UPS’s in the > >> event of a power failure, or in general. > >> > >> Legit? >
Re: CARP Cold Spare
I'm not sure why the hardware matters, but the two machines are a couple HP 1U Gen 8 Xeon servers. Suffice to say, they are identical and have supported hardware configurations for OpenBSD. Of course I _could_ run one off direct power, but it would be a terrible idea. The location is notorious for power surges, blips that are enough to reboot servers and several-second brown-outs. So, not connected to the UPS is just asking for damages. They experience multi-hour blackouts what seems like once a month; this is where the desire to limit the draw on the UPS's comes from. To ensure we make it through without having to shut down. Remote access is of primary concern, both for me for support, since I'm geographically far enough away that being on-site is not feasible, and to the customer, who just wants to stay home and work on systems in the office. Configurations on the servers almost never change (simple firwall), so besides having to run a quick syspatch and reboot once at time of failover, I don't see maintenance being so bad. I keep config files backed-up otherwise centrally for quick restore to the running box as well. My primary concern here is if CARP / pfsync will have issues with the one machine being down a majority of the time. Based on the FAQ, I think not, but have no practical experience. > On Sep 25, 2021, at 3:00 AM, jslee wrote: > > Hi, > > You haven’t said anything about your hardware platform, but could you run one > of them on non-UPS power? Then you’d still have one online when (*not* if) > the UPS fails, and also they’ll both normally be online for maintenance, > syspatch, config changes etc > > I do recall installing a pair of identical servers at the same time and > having them both fail a year later within an hour of each other, both with > seized CPU fans, so I am somewhat sympathetic to your idea. But I think the > practical cost of maintenance may be rather high > > John > > >> On Sat, 25 Sep 2021, at 08:13, Don Tek wrote: >> Would there be any ‘problem’ with configuring a 2-machine CARP setup >> and then just keeping one machine powered-off until needed? >> >> I realize this defeats live failover, but this is not a requirement for >> my customer. >> >> I just want them to be able to, in the event of a primary machine >> failure, power-on the secondary and have it take over. Logic here is >> to otherwise not have the secondary sucking power off the UPS’s in the >> event of a power failure, or in general. >> >> Legit?
CARP Cold Spare
Would there be any ‘problem’ with configuring a 2-machine CARP setup and then just keeping one machine powered-off until needed? I realize this defeats live failover, but this is not a requirement for my customer. I just want them to be able to, in the event of a primary machine failure, power-on the secondary and have it take over. Logic here is to otherwise not have the secondary sucking power off the UPS’s in the event of a power failure, or in general. Legit?
Re: Checking Routes/Gateways For Good Connection
On 8/29/2010 11:54 AM, Henning Brauer wrote: when pf sees that packet it is outbound on em0. you are logging that fact. then pf re-routes via em1. when pf sees it again on em1, you log that fact. My tcpdump output does not seem to confirm this. For instance: $ traceroute -m 4 -s 172.16.0.1 -n google.com $ sudo tcpdump -n -e -ttt -i pflog0 host 172.16.0.1 tcpdump: listening on pflog0, link-type PFLOG Aug 30 13:13:09.622700 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33435: udp 12 [ttl 1] Aug 30 13:13:14.630584 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33436: udp 12 [ttl 1] Aug 30 13:13:19.639902 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33437: udp 12 [ttl 1] Aug 30 13:13:24.649161 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33438: udp 12 Aug 30 13:13:29.658493 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33439: udp 12 Aug 30 13:13:34.667819 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33440: udp 12 Aug 30 13:13:39.677161 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33441: udp 12 Aug 30 13:13:44.686542 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33442: udp 12 Aug 30 13:13:49.695834 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33443: udp 12 Aug 30 13:13:54.705161 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33444: udp 12 Aug 30 13:13:59.714426 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33445: udp 12 Aug 30 13:14:04.723664 rule 42/(match) pass out on em1: 172.16.0.1.58471 209.85.225.104.33446: udp 12 Traceroute's defaults dictate a 5 second wait between probes and 3 probes per hop. I forced my max_ttl to 4 (hops). I get exactly 12 lines of log corresponding to (3 probes * 4 hops) and the log shows 5 seconds between hops. So where are the log lines for the re-routes? It appears to me PF is ignoring my route-to(s), or it is ignoring the source and not matching, and the request is simply going out whichever of my two multipath default routes gets chosen at the time.
Re: Checking Routes/Gateways For Good Connection
Well, I thought I had this issue worked out, but my pf rules aren't evaluating as I expected them to: PF Rules: (rule number prepended, these are the _last_ 6 lines in my pf.conf) 39:pass out quick log on em0 from 172.16.0.1 route-to (em0 192.168.0.1) 40:pass out quick log on em1 from 172.16.1.1 route-to (em1 10.10.0.1) 41:pass out log on em0 42:pass out log on em1 43:pass out log on em0 from em1 route-to (em1 10.10.0.1) 44:pass out log on em1 from em0 route-to (em0 192.168.0.1) Tests: $ traceroute -s 172.16.0.1 -n google.com Tcpdump pflog0 output: Aug 27 15:35:16.418090 rule 42/(match) pass out on em1: 172.16.0.1.34561 74.125.45.106.33438: udp 12 Aug 27 15:50:01.658596 rule 41/(match) pass out on em0: 172.16.0.1.63615 74.125.45.103.33444: udp 12 Why are these packets not being caught by rule 39 and always going out the em0 gateway?
Checking Routes/Gateways For Good Connection
I've recently implemented a firewall with two internet connections using multipath routing and round-robin outbound load balancing. I am looking for a solution from the shell to detect failure of these two internet gateways so I can force routing and pf changes from a script. I need something more robust than simply checking to see if the interface is up or down. I have managed a solution using traceroute that allows me to accomplish half of my goal. I can detect a failure and down that route, however, once I delete the default route from the routing table for the failed connection, I can no longer test it with traceroute. This is because it doesn't appear to me that OpenBSD's traceroute allows forcing an interface to work on. I am looking for better solutions from some of you more experienced users. Any suggestions are welcome. don..
Re: firewall rukes for OPC?
You are likely dealing with an OPC Client that uses DCOM on TCP 135. Not sure if you want to open this to the public though. On 7/22/2010 1:58 PM, stan wrote: I need to allow an OPC client and server to connect through one of my firewalls. Can anyone tell me what ports I need to open up for this to work?
