Aldo Bucchi wrote:
Hi All,
= About Data and State =
Using any of the Virtuoso Universal Sever AMIs for Amazon EC2, what
are the recommended guidelines for persistence?
I can see that you suggest creating an S3 account ( but there's no
further touching on the topic ), which brings me to the following set
of questions:
How do data lifecycle and AMI lifecycles play along?.
Can something be expected to happen transparently? What, exactly?
You can set up online incremental backups that go to an FTP, WebDAV, or
S3 Server (choice is yours).
The EC2 Extension vad provides the UI for configuring the backup syncs
to the destinations you choose.
What has to be done manually?
Just setting up the Backup Sync Job.
Any tricks for using an EBS?
We need to make a note about this. All you do is:
1. Instantiate AMI
2. Allocate the EBS volumes
3. Update your INI so that the DB is stripped across the EBS volumes
4. Reboot AMI or just log into the AMI and restart the Virtuoso instance
Best practices? etc.
The usecase I have is fairly common. I would like to have an instance
up in the cloud but not necessarily up 24/7 for any number of reasons.
At any point in time, I would like to bring it back to life at the
point ( packages, data, users, apps, etc ) where I left it to keep on
working.
This is a Virtuoso instance startup and shutdown matter within an AMI.
If you want to put the AMI off and on, then you must be ready to restore
from backup each time.
Before this I had built my own AMIs and I just moved some files around.
But now that this thing is plug & play, I wonder what the "official" idea is.
As expressed above :-)
If there is more than one viable option, then I would love to see an
extra step where I could tell my "Virtuoso Cloud Edition" about my
persistence strategy(ies).
= About Configuration =
Another probably useful idea would be to allow all ( or partial )
config of a Virtuoso instance to be represented as RDF. That way, I
could launch a virtuoso AMI with a certain state just by passing the
URL to an RDF document (
http://foo.com/virtuoso-xx-xx-xx-with-ods-safe-sparql-config-data.rdf
) or the data contained inside, which in turn allows me to pipeline
this into more complex, SW/REST friendly architectures.
This would be feasible once we implement the Backup to RDF dump feature :-)
For example:
http://foo.com/privateAPI/launchVOS?ElasticIP=x.x.x.x&config={urlToConfig}
could be the
Which is in turn a URL, etc. I could create a simple ontology where
this could be the value of a "turnOn" property.
And so the power of we architecture and REST stacks up.
Anyway, the sole fact that there is ONE step by step instructions page
smells that there might be something unRESTful about this.
Yet another place for innovation, perhaps.
Yes, the current deliverable is more about the AMI in the Clouds and
less about REST.
Kingsley
Best,
A
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
