user4382: I am working on a block producer failover script and am wondering if there is a penalty for having two block producing nodes running at the same time. Basically there could be a slight overlap where 2 BPs are up until the Cronjob I create restarts one as a relay. Reading through different forms I see posts saying that there is a penalty for the pool who runs 2 BPs at the same time. I am looking for details of that penalty as well as an answer to if I am better off programming it to make sure there is ALWAYS only 1 BP online and thus sacrificing a small amount of pool BP uptime (like 2 minutes max). Or programming it to maximize uptime and sacrifice having to BPs online for a small amount of time (~ 2 mins).
Thanks for the help in advance!

user4413: Don't know the answer for your question, but I´d avoid that, create a custom script to restart the second node in Core Mode (BP). Therefore the second node is running in relay mode until activated by a custom event

user4290: I was thinking same about same problem!
First you don't need to have BP all time online. It should be online only when Slot Leader is assigned to you, basically a time when you should forge a block and this is known ahead.
Second, I personally think technically you can have 2 BPs online. Your relays should have topology.json were you can set only 1 producer. So technically relays connects to BP and then it forges a block, if I understood that part correctly. So technically you can have 2 BPs up and running simultaneously and I even have it in my setup, most important that you relays are connected to only one BP.
Per my understanding BPs are connected to relays and your relays are connected to BPs.
In perfect world you can have them online simultaneously only, I think you should not allow one relay to connect to one BP and other relay to another BP.
So probably in your place I would close FW between backup-BP and relays(but you need to recheck it, maybe if we totally block traffic BP will not be in sync) and when main BP is down, you can open FW.
In my current testnet setup I have configured main BP with hostname and when it is down route 53 change IP of that hostname to IP of Backup-BP and relays switches automatically to backup-BP. After experimenting a while with this approach I found out that when main-BP is back online relays do not want to switch back, because connection is up and running relays simply don't need to make new DNS request. So probably I need to write a script what will either restart backup-BP after main-BP is online or I need to play with FW as described below.
Here are my post in Cardano Forum about this:
https://forum.cardano.org/t/redundancy-architecture-what-i-have-in-plan-please-criticize-it/78297

user4313: Running 2 block producers is not a recommended option.
Network can penalize.
One option you can do is failover BP. Care should be taken that only one node is acting as BP is used while producing blocks.
I would recommend a private relay (a relay which is not registered in your pool certificate). The advantage of this is that you can quickly convert this to a failover BP and dont have to deal with topology or db related issues. This also helps incase you get DDOS on your registered relays. Ofcourse you will need scripts to have this failover BP. few pools in armada-alliance are looking at this resiliency of stakepool especially for baremetal pools. Here is an idea from my friend QXT pool
https://twitter.com/PgwadaS/status/1451218689135579142

user249: I don't know what happens if both BPs have the exact same operating node certificate, but if either of the BPs has an older certificate, there is no penalty. I used to run two BPs. I switched nodes by updating the operating node certificate (when creating new KES key pairs). The node with the newer certificate creates the assigned block.
This was just an experiment and not very helpful for me as we can calculate our block leader assignment date 1.5 days in advance. Instead of maintaining two nodes, I only have to stay online with one BP when I'm producing a block.

4382: <p>I am working on a block producer failover script and am wondering if there is a penalty for having two block producing nodes running at the same time. Basically there could be a slight overlap where 2 BPs are up until the Cronjob I create restarts one as a relay. Reading through different forms I see posts saying that there is a penalty for the pool who runs 2 BPs at the same time. I am looking for details of that penalty as well as an answer to if I am better off programming it to make sure there is ALWAYS only 1 BP online and thus sacrificing a small amount of pool BP uptime (like 2 minutes max). Or programming it to maximize uptime and sacrifice having to BPs online for a small amount of time (~ 2 mins).</p>
<p>Thanks for the help in advance!</p>
 4413: <p>Don't know the answer for your question, but I´d avoid that, create a custom script to restart the second node in Core Mode (BP). Therefore the second node is running in relay mode until activated by a custom event</p>
 4290: <p>I was thinking same about same problem!
First you don't need to have BP all time online. It should be online only when Slot Leader is assigned to you, basically a time when you should forge a block and this is known ahead.</p>
<p>Second, I personally think technically you can have 2 BPs online. Your relays should have topology.json were you can set only 1 producer. So technically relays connects to BP and then it forges a block, if I understood that part correctly. So technically you can have 2 BPs up and running simultaneously and I even have it in my setup, most important that you relays are connected to only one BP.</p>
<p>Per my understanding BPs are connected to relays and your relays are connected to BPs.</p>
<p>In perfect world you can have them online simultaneously only, I think you should not allow one relay to connect to one BP and other relay to another BP.</p>
<p>So probably in your place I would close FW between backup-BP and relays(but you need to recheck it, maybe if we totally block traffic BP will not be in sync) and when main BP is down, you can open FW.</p>
<p>In my current testnet setup I have configured main BP with hostname and when it is down route 53 change IP of that hostname to IP of Backup-BP and relays switches automatically to backup-BP. After experimenting a while with this approach I found out that when main-BP is back online relays do not want to switch back, because connection is up and running relays simply don't need to make new DNS request. So probably I need to write a script what will either restart backup-BP after main-BP is online or I need to play with FW as described below.</p>
<p>Here are my post in Cardano Forum about this:</p>
<p><a href="https://forum.cardano.org/t/redundancy-architecture-what-i-have-in-plan-please-criticize-it/78297" rel="nofollow noreferrer">https://forum.cardano.org/t/redundancy-architecture-what-i-have-in-plan-please-criticize-it/78297</a></p>
 4313: <p>Running 2 block producers is not a recommended option.
Network can penalize.
One option you can do is failover BP. Care should be taken that only one node is acting as BP is used while producing blocks.
I would recommend a private relay (a relay which is not registered in your pool certificate). The advantage of this is that you can quickly convert this to a failover BP and dont have to deal with topology or db related issues. This also helps incase you get DDOS on your registered relays. Ofcourse you will need scripts to have this failover BP. few pools in armada-alliance are looking at this resiliency of stakepool especially for baremetal pools. Here is an idea from my friend QXT pool
<a href="https://twitter.com/PgwadaS/status/1451218689135579142" rel="nofollow noreferrer">https://twitter.com/PgwadaS/status/1451218689135579142</a></p>
 249: <p>I don't know what happens if both BPs have the exact same operating node certificate, but if either of the BPs has an older certificate, there is no penalty. I used to run two BPs. I switched nodes by updating the operating node certificate (when creating new KES key pairs). The node with the newer certificate creates the assigned block.
This was just an experiment and not very helpful for me as we can calculate our block leader assignment date 1.5 days in advance. Instead of maintaining two nodes, I only have to stay online with one BP when I'm producing a block.</p>
