Reblog > Deterritorialized House – Inhabiting the data center, sketches…
By fabric | ch
—–
Along different projects we are undertaking at fabric | ch, we continue to work on self initiated researches and experiments (slowly, way too slowly… Time is of course missing). Deterritorialized House is one of them, introduced below.
Reblog > Decentralizing the Cloud: How Can Small Data Centers Cooperate?
Note: while reading last Autumn newsletter from our scientific committee partner Ecocloud (EPFL), among the many interesting papers the center is publishing, I stumbled upon this one written by researchers Hao Zhuang, Rameez Rahman, and Prof. Karl Aberer. It surprised me how their technological goals linked to decentralization seem to question similar issues as our design ones (decentralization, small and networked data centers, privacy, peer to peer models, etc.)! Yet not in such a small size as ours, which rather look toward the “personal/small” and “maker community” size. They are rather investigating “regional” data centers, which is considered small when you start talking about data centers.
Cookbook > Setting up your personal Linux & OwnCloud server
Note: would you like to install your personal open source cloud infrastructure, maintain it, manage your data by yourself and possibly develop artifacts upon it, like we needed to do in the frame of this project? If the answer is yes, then here comes below the step by step recipe on how to do it. The proposed software for Cloud-like operations, ownCloud, has been chosen among different ones. We explained our (interdisciplinary) choice in this post, commented here. It is an open source system with a wide community of developers (but no designers yet).
We plan to publish later some additional Processing libraries — in connection with this open source software — that will follow one of our research project’s objectives to help gain access to (cloud based) tools.
Would you then also like to “hide” your server in a traditional 19″ Cabinet (in your everyday physical or networked vicinity)? Here is a post that details this operation and what to possibly “learn” from it –”lessons” that will become useful when it will come to possible cabinet alternatives–.
Setting up our own (small size) personal cloud infrastructure. Part #3, reverse engineer the “black box”
At a very small scale and all things considered, a computer “cabinet” that hosts cloud servers and services is a very small data center and is in fact quite similar to large ones for its key components… (to anticipate the comments: we understand that these large ones are of course much more complex, more edgy and hard to “control”, more technical, etc., but again, not so fundamentally different from a conceptual point of view).
Documenting the black box… (or un-blackboxing it?)
You can definitely find similar concepts that are “scalable” between the very small – personal – and the extra large. Therefore the aim of this post, following two previous ones about software (part #1) –with a technical comment here– and hardware (part #2), is to continue document and “reverse engineer” the set up of our own (small size) cloud computing infrastructure and of what we consider as basic key “conceptual” elements of this infrastructure. The ones that we’ll possibly want to reassess and reassemble in a different way or question later during the I&IC research.
However, note that a meaningful difference between the big and the small data center would be that a small one could sit in your own house or small office, or physically find its place within an everyday situation (becoming some piece of mobile furniture? else?) and be administrated by yourself (becoming personal). Besides the fact that our infrastructure offers server-side computing capacities (therefore different than a Networked Attached Storage), this is also a reason why we’ve picked up this type of infrastructure and configuration to work with, instead of a third party API (i.e. Dropbox, Google Drive, etc.) with which we wouldn’t have access to the hardware parts. This system architecture could then possibly be “indefinitely” scaled up by getting connected to similar distant personal clouds in a highly decentralized architecture –like i.e. ownCloud seems now to allow, with its “server to server” sharing capabilities–.
See also the two mentioned related posts:
Setting up our own (small size) personal cloud infrastructure. Part #1, components
Setting up our own (small size) personal cloud infrastructure. Part #2, components
Maps of data center localizations
Although data centers are unevenly distributed, but it’s intriguing to observe the way they’re located spatially. It’s difficult to find world maps but here are some examples I found interesting, but it’s totally not exhaustive (lots of them are not documented). Also note that any queries on image search engine about data center geography leads to weather-related visualizations (which generally influence energy/water consumption for this infrastructure).
The largest US data-centers (by Nicolas Rapp, data by Dave Drazen at Geo-Tel)
I&IC Workshop #2 with James Auger at HEAD: Design Implications
Based on the concepts and scenarios produced in our second workshop, we decided to work on the design implications of such projects. More specifically, we realized the set of contexts (religion, music, etc.) the workshop participants worked on share common traits: the needs for a cloud infrastructure was fairly similar and let to the idea of a basic “data unit”. Such a mobile system would act as a mini-data center.
