For a deployment of the upcoming wikidata query service we'll need some hardware.
Initially, we probably need one work machine and one spare for disaster recovery (full recovery loading from dump takes several days, so unless we want to live the life of danger, we'd need a hot spare). Exact specs TBD soon.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| wdqs: install as jessie, add partman recipe | operations/puppet | production | +85 -3 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T67626 [Epic] Support for queries on-wiki (automated list generation) | |||
| Resolved | Smalyshev | T85159 [EPIC] Deploy a Wikidata Query Service into production | |||
| Resolved | Joe | T86561 Wikidata Query Service hardware | |||
| Resolved | Smalyshev | T104879 Define the details of the hardware we need to run WDQS | |||
| Resolved | • Cmjohnson | T105904 relocate wmf3544 from row d into any other row | |||
| Resolved | • Cmjohnson | T106320 wmf3543 can't install from PXE | |||
| Resolved | • Cmjohnson | T107152 Change hardware RAID controller on wmf3543, wmf3544 |
Do we want to have the Cassandra and Titan nodes be in the same rack as I assume that query performance is very latency sensitive?
I don't think that there is a huge enough difference in latency between rows that would make it worth compromising availability. Cassandra nodes are spread out across racks (rows in our case) in order to improve availability by avoiding correlated failures that affect a single row. I think we should do the same for the Titan nodes.
Different rows for availability is one thing. We need to think about how to distribute the service to two different data centers as well, and should build this out in both from the start. Latency certainly is a significant factor there.
Based on what we heard regarding Titan/WQS lately, I think we can safely put this on hold and mark it as stalled, correct?
Yes, I was waiting for this evening's WQS meeting before reassessing priority/status, but marking it stalled is fair.
Based on T104879, I think what we need is:
For starters, 2 servers.
Update from IRC discussion:
We'll be allocating two systems for this:
Dell PowerEdge R420, Dual Intel Xeon E5-2440, 64GB Memory, Dual 300GB SSD, H310 Mini Raid Card
wmf3543 - currently in d3-eqiad, and staying there
wmf3544 - currently in d3-eqiad, and relocating into another row
As such, this task will have a blocker to completion, being the relocation of the second host and its network setup, etc...
Change 225848 had a related patch set uploaded (by Giuseppe Lavagetto):
wdqs: install as jessie, add partman recipe
Change 225848 merged by Giuseppe Lavagetto:
wdqs: install as jessie, add partman recipe
I am currently installing wdqs1001; upon validation of the install, I'll add wdqs1002 as well.
wdqs1001 installed just fine (after I figured out I needed at least one deploy for trebuchet to work).
Installing wdqs1002 now, then I'll set up the LVS config.
Both servers are up and running and the wdqs-blazegraph service is running and the banner page shows on port 80.
I will finish this work (adding LVS and eventually varnish support).
Stas and James can now log into the machine and play with it - it's still not exposed to the public internet