|
From: | Todd Fleisher |
Subject: | Re: [Sks-devel] SKS scaling configuration |
Date: | Sun, 17 Feb 2019 09:18:11 -0800 |
Hi Jonathon, I've previously spoken with Kristian about this off-list in an attempt to improve the performance & resilience of my own server(s) pool(s), so let me share his recommendations which I’ve been using with minimal issues. The setup uses a caching NGINX server to reduce load on the backend nodes running SKS. His recommendation is to run at least 3 SKS instances in the backend (I’m running 4). Only one of the backend SKS nodes is configured to gossip with the outside world on the WAN, along with the other backend SKS nodes on the LAN. The NGINX proxy is configured to prefer that node (the one gossiping with the outside world - let’s call it the "primary") for stats requests with a much higher weight. As a quick aside, I’ve observed issues in my setup where the stats requests are often directed to the other, internal SKS backend nodes - presumably due to the the primary node timing out due to higher load when gossiping. This then gets cached by the NGINX proxy and continues to get served so my stats page reports only the internal gossip peer’s IP address vs. all of my external peers. If Kristian or anyone else has ideas on how to mitigate/minimize this, please do share. Whenever I check his SKS node @ http://keys2.kfwebs.net:11371/pks/lookup?op=stats I always find it reporting his primary node eta_sks1 with external & internal peers listed. Here are the relevant NGINX configuration options. Obviously you need to change the server IP addresses & the hostname returned in the headers: And in server context: Here is my sksconf file:
Another important item that was recently discussed on the list is to ensure you build your SKS DB with a DB_CONFIG file in your DB & PTree sub-directories to avoid issues with DB logfiles building up:
Regarding the sizing of virtual machines that host the SKS nodes. I originally provisioned mine as 4 VCPU, 4 GB of RAM, & 50 GB of disk storage (currently showing ~20GB used). However, with the recent additions to my sksconf file to try and address poison keys I found it necessary to increase them to 8 GB of RAM to avoid swapping. I could probably down size the VCPU count, as I rarely see that spike above 50% (out of 400%). I use Ubuntu Bionic (18.04 LTS), only after installing the SKS package that ships with that release I replace it with the version built to refuse at least one of the poison keys as discussed @ https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html. The actual link to download the package file is @ https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages. Hopefully one day it will be promoted into to ship by default without having to download and install manually. I think that about covers it, but if you have any questions or notice any mistakes please let me know. Hopefully you and others will find this to be a useful, one-stop-shop resource for setting up a more solid pool of SKS servers. Cheers, -T
|
signature.asc
Description: Message signed with OpenPGP
[Prev in Thread] | Current Thread | [Next in Thread] |