psarna
commented
9 years ago Oh, thanks for noticing 404 error, it will probably be fixed after the weekend. Meanwhile you can use LizardFS whitepaper from CeBit webpage (in the Downloads section): http://www.cebit.de/product/lizardfs/557479/C273009
Now for the list of questions:
- LizardFS is actually always layered on top of other file systems - chunkservers need one to store data. There is no native support of Amazon S3, but I guess you can export it via NFS.
- Yes, they can.
- Yes, you can.
- You can use topology feature to assure that: https://github.com/lizardfs/lizardfs/blob/master/doc/mfstopology.cfg.5.txt
5.You can avoid that with the use of shadow master servers. Failover doesn't have to be manual.
- It's tricky, but I think it may be doable. If it's possible for you to create a temporary local chunkserver and mount point on a server in the same cloud, all needed actions would be to copy all the data to mount point.
- Let's assume that you have a chunkserver, which uses /mnt/chunk1 directory to store data and /mnt/chunk1 is mounted as a remote file system on some cloud.
Then those actions:
- turn chunkserver off
- unmount /mnt/chunk1
- export-to-disk from a cloud and put all the data in /mnt/chunk1
- turn chunkserver on
would result in chunkserver having all its chunks like nothing happened, not even realising that it uses local data now instead of contacting the cloud.
The Whitepaper is missing (Error 404 whether I use the link on the website or the links in various places here in Github). So, a couple of questions (which might have been answered there). My use case is for relatively small amounts of storage (lots and lots of small files, several multi-gig files but total about 2TB, so less than one modern disk) but I am trying to achieve a diverse storage pattern for good protection without massive cost.
My ideal would be a distributed filesystem with three types of storage: online local (adjacent to clients, fast), encrypted local backup (close to clients so it can be maintained quickly and easily, but typically in another room to reduce fire/flood risk and encrypted), encrypted cloud storage (slow, high access and data transfer costs, encrypted). With sensible access optimisations (use local copies for preference, do not copy data from cloud unless there is no alternative) but with no single point of failure (so, for example, clients can use the backup or cloud copies if their local server fails).
I am wondering how close lizardfs can get to this so have a few questions:
1) Can lizardfs be layered on top of other filesystems (for example, an encrypted filesystem or a cloud filesystem, either/both of which might also be a userspace filesystem)? Can it access any cloud filesystems (e.g. Amazon S3) natively?
2) Can multiple logical chunkservers (or group of chunks with similar attributes) be run on the same (physical) server? For example, could I have one server which manages chunks stored on fast disks for online access and also other chunks using an encrypted filesystem stored on NFS disks on a NAS?
3) Can I configure the multiple copies of data such that I am guaranteed one copy in an online chunk, one in an encrypted local backup and one in the cloud?
4) Can I manage data access so that local online storage is always read (and written first) unless it has gone offline, in which case local backup storage is used next, and cloud only when absolutely necessary?
5) Can I avoid the master being a single point of failure? Would failover have to be manual?
6) In order to set this up, I need to avoid uploading all the data to the cloud using the slow and expensive access. I can (and do) use disk import capabilities to load cloud data and there are fairly current copies of the data in the cloud already. Can lizardfs use that data already (presumably not as it is not chunkified)? If not, can I run some process in a server in the same cloud (which has fast access to the cloud data) to somehow convert the files to chunks and configure the metadata so that lizardfs knows that these new chunks are duplicates of the chunks in the local chunkservers and avoid moving the data itself to/from the cloud?
7) In the opposite direction, in the case of a disaster recovery I would use export-to-disk to retrieve the data from the cloud (not download it) -- could I then somehow tell lizardfs that the chunks are now available in a local chunkserver once I have received the disk from the cloud service?