Re: [Sks-devel] Clustering (Was: New Keyservers and Dumps)

[Kristian Fiskerstrand]

[Sent from my iPad, as it is not a secured device there are no cryptographic 
keys on this device, meaning this message is sent without an OpenPGP signature. 
In general you should *not* rely on any information sent over such an unsecure 
channel, if you find any information controversial or un-expected send a 
response and request a signed confirmation]

> On 26 Aug 2018, at 18:44, Alain Wolf <address@hidden> wrote:
> 
> Hi
> 
> Am 24.08.2018 um 14:36 wrote Kristian Fiskerstrand:
>> On 08/24/2018 11:36 AM, Gabor Kiss wrote:
>>> A question:
>>> Does an SKS cluster need multiple storage space,
>>> or nodes can share the database?
>> 
>> the DB/storage needs to be separate, but it doesn't require multiple VMs
>> although I tend to just spin up a new one for each node.
>> 
> 
> So to clarify, I run a Ubuntu-server 18.04 and assuming I have 100+ GB
> of free disk-space:
> 
> 1) I make two additional copies of /var/lib/sks (22GB as of today).
> 
> 2) I give them each a nodename in sksconf, but leave the hostname as
>   it is.
> 

RIght.. obviously also ports needs to be distinct 

> 3) I peer all of them with each other in their membership files.
> 
> 4) I somehow convince systemd to run three instances of sks and
>   sks-recon, each with its own working-dir.
> 
> 5) I tell my Nginx to proxy all three of them.
> 
> 6) I ask around for peers to my two new instances.
> 
> 
> A) Is that it?

Yup.. that is pretty much it. I also recommend a 10 minute cache on the load 
balancer 

> 
> B) Would this be useful?
> 
Very much so.. that should be much more reliable
> 
> Note 1:
> I only one single external IPv4-Address, but a delegated IPv6 prefix. So
> IPv4 recon will be limited to one of the three instance.

That is what I use myself.. one primary doing external gossipping.. each slave 
only gossip with master.. one reason for this is you don’t want slaves 
gossiping with others as that reduces time it is available for respons and you 
always want at least one node responding.