As promised, we put your money to work immediately. Not only have we paid for Inkbunny's main server, but we found a way to use the excess funds in line with our goal of obtaining three years' hosting.
From low-powered backup to secondary server
As noted in our previous FAQ, we planned to upgrade our on-site backup server this year. After all, Inkbunny will soon be larger than 1TB - we just passed 600,000 submissions and 260,000 members.
The deals were so good that we managed to lease a highly capable secondary server with the excess: HP DL120 G7 (photos) - Quad-core Xeon E3-1270 - 16GB DDR3-1333 ECC RAM - 4x1TB SATA2 RAID5
This configuration also comes with a 100TB/month network allowance, at a speed of 1Gbps. To put that in perspective, Inkbunny currently uses around 12TB/month, on a 100Mbps line.
Compared to our current backup server, it has 4x the raw disk space, 8x CPU performance, 16x RAM, 10x bandwidth, and 20x network allowance - all for just €2003.40 (~US$2400) for three years.
What's it for?
Aside from submission and database backup, we intend to use this server in several new ways: * to offload public content serving, decreasing network and disk utilization on Inkbunny's main server * to test new versions of Inkbunny's software, database, and OS in a near-production environment * to run a warm/hot standby database, decreasing the data-loss window in the event of server failure
Of course, its primary backup role remains important. We don't want to be shipping hard drives in a crisis!
Didn't you say you didn't need another server?
For years, we've maintained an on-site backup server. We took this opportunity to expand its capabilities beyond mere file backups, after evaluating the likely cost of main-server upgrades if we didn't do so.
We've seen increasing use of bulk downloaders, with hours-long bursts above 60Mbps. We consider this legitimate use, but it has the potential to cause network congestion and excessive disk usage. At the same time, we want to offer new high-bandwidth features without saturating our network link.
The new server will help to solve these issues. We can serve public files and thumbnails from it, while using the main server for the actual pages and private content. It should also ease future development.
Weren't you considering a U.S.-based cache?
Yes; we still are. This is a good first step. Once we split the load, it'll be easier to distribute further. We considered leasing one in a separate sale, but the deals weren't as good.
Why this server/configuration? Why not just upgrade bandwidth?
It's a cheap way of getting 100TB/month transit and a 1Gbps port. Upgrading our main server would be nearly as expensive, and we'd "lose" its unmetered 100Mbps connection (worth ~30TB by itself). Why broaden a road when you can build a new one and keep the one you have for the same price?
We considered a less-capable system with 10TB/mo. for €1000 - but this way, we get copious bandwidth and RAM for caching, and a quad-core CPU of the same architecture as our main system, as well as disk space for backups. As a bonus, our host ran out of the E3-1230, so we got a free 200Mhz upgrade.
We got 50% off the list price (in addition to a 30% contract-length discount) because it's a three-year-old model and limited to a maximum of 32Gb RAM and a single CPU. That's fine for our purposes.
In conclusion
It wasn't at all clear whether we'd raise what we needed, but you came through, and more. We now have a solid foundation for future growth, thanks to the generosity of our members.
Many, many thanks to all those who contributed. We'll continue to accept donations to fund our other expenses and future payments. However, we encourage you to consider a commission or two as well!
That sounds very nice what you snatched there. I think that should make Inkbunny run even smoother and make development a lot easier. Also take down times should be reduced too, as you can test updates/upgrades on your new server. Which I approve!
Also sorry, for that I am one of those bulk downloaders too, but I'm thinking of a few ways to reduce load. So that you guys can concentrate on other stuff! :)
So I'm happy to see all those donations are taken for good measure and love to see what future brings!
That sounds very nice what you snatched there. I think that should make Inkbunny run even smoother a
It's a good deal! I couldn't find 100TB that cheap anywhere else, and it gives us far more flexibility.
Bulk downloads are fine, although if you're doing it regularly it helps to schedule it for our "quiet time" (between 08:00-14:00 UTC). If you can avoid "breaking" caching, that will also help (e.g. there's no need to send a SID/query parameters, cookies, or a referrer for public files/thumbnails). We'll work on this on our end as well, once we get our cache set up.
We try to schedule maintenance for when it's quiet; unfortunately this impacts early-rising Europeans. Sorry! But better to have a few minutes every few weeks than hours or days of unexpected downtime.
It's a good deal! I couldn't find 100TB that cheap anywhere else, and it gives us far more flexibili
Yes, indeed! It's not been necessary up to this point, but Varnish is what we plan to use on our cache nodes. I have experience with its use for WikiFur and Flayrah. Edit: We're probably going to go with nginx instead, for various reasons. But it's cool, too!
Yes, indeed! It's not been necessary up to this point, but Varnish is what we plan to use on our cac
Congratulations on reaching and exceeding the goal, and a big THANK YOU to all those who donated! I'm looking forward to an awesome and wonderful 2015, full of much InkBunny goodness! :-D
Congratulations on reaching and exceeding the goal, and a big THANK YOU to all those who donated! I
It's enough to make me think, ponder and appreciate what a big difference the upgraded new products are going to bring to the table in the near future. You guys rock, and here's to a safe and stable network.
It's enough to make me think, ponder and appreciate what a big difference the upgraded new products
This is why Inkbunny is so awesome, you guys raise money and immediately tell us exactly how it'll be used. I hope this site keeps running for decades to come!
This is why Inkbunny is so awesome, you guys raise money and immediately tell us exactly how it'll b
It's pretty easy if you figure out what you want to buy ahead of time!
We had to scramble a bit to decide on the secondary server when the sale arrived, but we already had an idea of what we wanted - it was simply a matter of cost/benefit for the "wants" (e.g. 100TB was cheap, but 16->32Gb would have cost another $750; not cost-effective).
And yes, we would like to stick around, too. :-) That's how most sites get big - they stick around and don't fall over. Growth can be stressful, though!
It's pretty easy if you figure out what you want to buy ahead of time! We had to scramble a bit to
Yeah just sticking around isn't always enough- not to name any other similar sites that never seem to understand that "growth without toppling" part. Just keep doing what you guys are doing, it's been a fantastic site for the whole time I've been here. Also it's funny, when you replied to my journal on FA I had no idea who you were, but konwing about turning off friend requests on here was some seriously useful info (that I had never even thought to look up, I guess they weren't that annoying).
Yeah just sticking around isn't always enough- not to name any other similar sites that never seem t
If bulk downloads are legit use, would it be possible to publish guidelines on making their use more "friendly"? Letting people play nice will mean that at least some API authors will do so.
Simplest might be to publish your off-peak hours in the wiki where you link to the downloaders, and also in the API docs (requesting that downloader authors provide their users to schedule downloads if possible might have a good effect!).
Another option is to have a method to specifically request images from the overflow server, so that bulk activities can avoid affecting the main server.
If bulk downloads are legit use, would it be possible to publish guidelines on making their use more
The intended result of our future caching hierarchy is that content will only be accessed from the main server when it is not available on the secondary. This would be accomplished by changing the URL to point to the secondary server, which will transparently load the image from the main server if necessary.
That's a good idea, and I've added these times to the wiki ( https://wiki.inkbunny.net/wiki/Hacks,_S
We have two SSDs in RAID1 on our main server. Throughput isn't high enough to need SATA3, though, even for them - and for hard disks, it's more about how fast the heads can actually move.
One good part about leasing: if something breaks, our host has to fix it! Oh, and those are sample photos from a review; I imagine with more fans it would just be noisier. :-)
We have two SSDs in RAID1 on our main server. Throughput isn't high enough to need SATA3, though, ev
We felt bad about not using our backup server for more. Now it has the bandwidth, disk, RAM and CPU it needs to play a more significant role. Edit:And now it is!
We felt bad about not using our backup server for more. Now it has the bandwidth, disk, RAM and CPU
It's really an amazing blog great to get the relatives information through your site for all the people, I appreciate your efforts. Thank you for sharing your knowledge and experience with me https://letslearnirish.com/
It's really an amazing blog great to get the relatives information through your site for all the peo
