[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.
_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc