roelandp
I will be running a Block Producer server portfolio for EOS and therefore running for Block Producer for EOS. Ever since I got into contact with graphene / chainbase I am addicted to the ease of use of the software and it's (developer) community. I live in Amsterdam, am an avid kitesurfer, organise events am a dad of Viggo and was born and raised in a windmill. Read more about my personal life here.
Ps. I generally get high on low 'Missed Block' - counts. 1.5 years of witnessing/block producing for Steem: 17 blocks missed.
A helicopter-view developer eye, future social events, game hackathon promotions and more. I have several years of server administration experience, all the way from f*cking up my first dedicated box in 2000 with client data on it and no 1-on-1 copy via image back-ups (yeah, yeah) simply overwriting the Access Level rights by CHMOD'ding with a wrong placed [space] corrupting the server in 1 cmd. This event led me to go to the the data center at 1 AM and sitting there untill dawn and re-installing Ubuntu and then moving back the data from a backup. Nowadays I still run an app building company for tourguide apps and it's accompanying CMS which all run through a combination of services on my own servers, combined with Amazon Cloud infrastructure. In the future I would like to promote EOS on hackathons and social events.
Usually I run my graphene nodes on dedicated baremetal server boxes. As EOS is looking to be demanding server spec wise very soon, I am seriously considering running the main nodes in a dedicated rack in Amsterdam, with min. 1 GBPS uplink and very close to AMS-IX. Backup nodes would be located in different locations. Currently I use datacenters in USA, Canada, France, Germany and The Netherlands.
Generally speaking my graphene witness (block producer) portfolio looks like a setup as listed below. This is just an indicative setup. I always run servers in multiple datacenters in multiple geographic locations. Another server generally runs monitor scripts and automatically switches over in failover cases. You can find such scripts on my Github.
Main Node - Dedicated box:
Backup Node - Dedicated box:
Seed Node - Dedicated box:
Monitoring Node(s) for swapping keys and administrative tasks
Note: as said above the EOS rack will most probably be way more extensive. I've been investigating custom build 1U's in an unmetered rack with low latency to main internet exchanges. For EOS.io I would initially launch on baremetal dedicated rent boxes and most probably migrate to this serious rack as soon as the network starts demanding more RAM.