Is the "upstream" Storage Server fully open source, or are parts of it closed source?
Are the RPMs to build one already in the Centos repo? If not, are there any plans to offer them?
I am looking for something free to use in Haiti, that will offer redundant file storage and automatic failover to a second set of hardware in case of a failure of the primary hardware.
If RHSS is not available or suitable, other suggestions welcome. I need a file system/server with:
* primary function is serving MP3 files for playback in a radio station environment in Haiti * if the system goes down all your clients (listeners) know it * they know it NOW * they know how long it takes to get it back up * High Availability as the primary concern * ability to administrate via web interface or similar by non-Linux-savvy IT staff. * ability to grow file system from 2-3TB to 20-50TB by simply adding disks and/or adding 'bricks' * clients will all be Windows computers, so files accessible by CIFS * critical application is read-only * prefer a system that would continue serving files even if the network goes down (but have not found such a system yet for Windows clients). This would require something like Ceph with a full (non-server) windows client, so the local node would continue to function until the network came back up. * throughput is not a large issue
Ted Miller Elkhart, IN
On 19.11.2012 13:48, Ted Miller wrote:
Is the "upstream" Storage Server fully open source, or are parts of it closed source?
Are the RPMs to build one already in the Centos repo? If not, are there any plans to offer them?
I am looking for something free to use in Haiti, that will offer redundant file storage and automatic failover to a second set of hardware in case of a failure of the primary hardware.
Ted,
Redhat Storage is based on GlusterFS which is fully open source and it works very well on Centos. You can install it from http://repos.fedorapeople.org/repos/kkeithle/glusterfs/epel-6/
A relatively recent guide here: http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-...
I recommend you get on their mailing list and IRC channel. http://www.gluster.org/interact/
Ted Miller wrote:
Is the "upstream" Storage Server fully open source, or are parts of it closed source?
Are the RPMs to build one already in the Centos repo? If not, are there any plans to offer them?
I am looking for something free to use in Haiti, that will offer redundant file storage and automatic failover to a second set of hardware in case of a failure of the primary hardware.
Should we assume that you're setting up h/a failover servers, with at least two nodes, and UPS, and a generator (and an adequate supply of fuel - I *have* read what happened in NYC...)? <snip> mark
On 11/19/2012 11:57 AM, m.roth@5-cent.us wrote:
Ted Miller wrote:
Is the "upstream" Storage Server fully open source, or are parts of it closed source?
Are the RPMs to build one already in the Centos repo? If not, are there any plans to offer them?
I am looking for something free to use in Haiti, that will offer redundant file storage and automatic failover to a second set of hardware in case of a failure of the primary hardware.
Should we assume that you're setting up h/a failover servers, with at least two nodes, and UPS, and a generator (and an adequate supply of fuel
Yes to everything. I am working on the H/A failover servers, 2-3 nodes. The other stuff -- generator w/ large fuel supply, inverters with battery bank bigger than your bed, is already in place. (Batteries can run the place for 4-8 hours before the inverters auto-start the generator.)
Ted Miller
On Mon, Nov 19, 2012 at 7:48 AM, Ted Miller tedlists@sbcglobal.net wrote:
If RHSS is not available or suitable, other suggestions welcome. I need a file system/server with:
- primary function is serving MP3 files for playback in a radio station
environment in Haiti * if the system goes down all your clients (listeners) know it * they know it NOW * they know how long it takes to get it back up
- High Availability as the primary concern
- ability to administrate via web interface or similar by non-Linux-savvy
IT staff.
- ability to grow file system from 2-3TB to 20-50TB by simply adding disks
and/or adding 'bricks'
- clients will all be Windows computers, so files accessible by CIFS
- critical application is read-only
- prefer a system that would continue serving files even if the network
goes down (but have not found such a system yet for Windows clients).
Is it possible to change the application so it uses http to get content or uses a distributed database natively? Distributed failure-tolerant systems are a lot easier if you don't even try to provide filesystem semantics that require a lot of atomic operations.
His flow mostly likes this,
Clients <-> Web services <-> Storage
Even the web servers will be making the call with another http services for the mp3 resource. He still needs the storage to put the files. gluster looks a good one to him. It looks like having most features of commercial products.
------------ Banyan He Blog: http://www.rootong.com Email: banyan@rootong.com
On 2012-11-20 1:12 AM, Les Mikesell wrote:
On Mon, Nov 19, 2012 at 7:48 AM, Ted Miller tedlists@sbcglobal.net wrote:
If RHSS is not available or suitable, other suggestions welcome. I need a file system/server with:
- primary function is serving MP3 files for playback in a radio station
environment in Haiti * if the system goes down all your clients (listeners) know it * they know it NOW * they know how long it takes to get it back up
- High Availability as the primary concern
- ability to administrate via web interface or similar by non-Linux-savvy
IT staff.
- ability to grow file system from 2-3TB to 20-50TB by simply adding disks
and/or adding 'bricks'
- clients will all be Windows computers, so files accessible by CIFS
- critical application is read-only
- prefer a system that would continue serving files even if the network
goes down (but have not found such a system yet for Windows clients).
Is it possible to change the application so it uses http to get content or uses a distributed database natively? Distributed failure-tolerant systems are a lot easier if you don't even try to provide filesystem semantics that require a lot of atomic operations.
Hi all,
Just encountered an strange bahavior of frequent 'find' command. I tried to use find to recursively remove .svn directories from my working place, 'find' command removed all the '.svn' directories successfully but reported errors on screen. Any one knows why it shows this behavior?
BTW, if I use command " find . type d -name '.svn' -print0 | xargs -0 -n1 /bin/rm -rf ", then it does the same job and reports no errors on screen at all. But still likes to understand why find have this behavior.
The screen and error prompts are attached below for your references. Thanks.
[root@centos_58_test_box workingDir]# find . -type d -name '.svn' ./.svn ./var/.svn ./var/myTestProj/projects/.svn ./var/myTestProj/projects/Production/.svn ./var/myTestProj/projects/Production/etc/.svn ./var/myTestProj/projects/Production/jobs/.svn ./var/myTestProj/.svn ./etc/.svn ./etc/myTestProj/.svn ./etc/myTestProj/ssl/.svn [root@centos_58_test_box workingDir]# find . -type d -name '.svn' -exec /bin/rm -rf '{}' ; find: ./.svn: No such file or directory find: ./var/.svn: No such file or directory find: ./var/myTestProj/projects/.svn: No such file or directory find: ./var/myTestProj/projects/Production/.svn: No such file or directory find: ./var/myTestProj/projects/Production/etc/.svn: No such file or directory find: ./var/myTestProj/projects/Production/jobs/.svn: No such file or directory find: ./var/myTestProj/.svn: No such file or directory find: ./etc/.svn: No such file or directory find: ./etc/myTestProj/.svn: No such file or directory find: ./etc/myTestProj/ssl/.svn: No such file or directory [root@centos_58_test_box workingDir]# find . -type d -name '.svn' [root@centos_58_test_box workingDir]#
Thanks.
On Mon, Nov 19, 2012 at 04:44:31PM -0800, Gelen James wrote:
[root@centos_58_test_box workingDir]# find . -type d -name '.svn' -exec /bin/rm -rf '{}' ; find: ./.svn: No such file or directory
[...]
"find" is attempting to open the ".svn" directory to see if there are any subdirectories to work on but it can't because you just deleted it.
You either need "-prune" to stop it going further down the tree or "-depth" to tell it to go down the tree first before running the -exec
Thanks a lot.
with -prune option, now the find command works too.
find . -type d -name '.svn' -prune -exec /bin/rm -rf '{}' ;
________________________________ From: Stephen Harris lists@spuddy.org To: CentOS mailing list centos@centos.org Sent: Monday, November 19, 2012 4:52 PM Subject: Re: [CentOS] strange 'find' tool behavior
On Mon, Nov 19, 2012 at 04:44:31PM -0800, Gelen James wrote:
[root@centos_58_test_box workingDir]# find . -type d -name '.svn' -exec /bin/rm -rf '{}' ; find: ./.svn: No such file or directory
[...]
"find" is attempting to open the ".svn" directory to see if there are any subdirectories to work on but it can't because you just deleted it.
You either need "-prune" to stop it going further down the tree or "-depth" to tell it to go down the tree first before running the -exec
On 11/19/2012 12:12 PM, Les Mikesell wrote:
On Mon, Nov 19, 2012 at 7:48 AM, Ted Millertedlists@sbcglobal.net wrote:
If RHSS is not available or suitable, other suggestions welcome. I need a file system/server with:
- primary function is serving MP3 files for playback in a radio station
environment in Haiti * if the system goes down all your clients (listeners) know it * they know it NOW * they know how long it takes to get it back up
- High Availability as the primary concern
- ability to administrate via web interface or similar by non-Linux-savvy
IT staff.
- ability to grow file system from 2-3TB to 20-50TB by simply adding disks
and/or adding 'bricks'
- clients will all be Windows computers, so files accessible by CIFS
- critical application is read-only
- prefer a system that would continue serving files even if the network
goes down (but have not found such a system yet for Windows clients).
Is it possible to change the application so it uses http to get content or uses a distributed database natively? Distributed failure-tolerant systems are a lot easier if you don't even try to provide filesystem semantics that require a lot of atomic operations.
Application is commercial, not changeable. It wants to see a local drive, if possible. Will tolerate (with warnings) a network share. Most of the critical operations are read-only (play back a file on the air).
Ted Miller
On 20.11.2012 01:15, Ted Miller wrote:
On 11/19/2012 12:12 PM, Les Mikesell wrote:
On Mon, Nov 19, 2012 at 7:48 AM, Ted Millertedlists@sbcglobal.net wrote:
If RHSS is not available or suitable, other suggestions welcome. I need a file system/server with:
- primary function is serving MP3 files for playback in a radio
station environment in Haiti * if the system goes down all your clients (listeners) know it * they know it NOW * they know how long it takes to get it back up
- High Availability as the primary concern
- ability to administrate via web interface or similar by
non-Linux-savvy IT staff.
- ability to grow file system from 2-3TB to 20-50TB by simply
adding disks and/or adding 'bricks'
- clients will all be Windows computers, so files accessible by
CIFS
- critical application is read-only
- prefer a system that would continue serving files even if the
network goes down (but have not found such a system yet for Windows clients).
Is it possible to change the application so it uses http to get content or uses a distributed database natively? Distributed failure-tolerant systems are a lot easier if you don't even try to provide filesystem semantics that require a lot of atomic operations.
Application is commercial, not changeable. It wants to see a local drive, if possible. Will tolerate (with warnings) a network share. Most of the critical operations are read-only (play back a file on the air).
Then it looks like GlusterFS is your only choice. Otherwise Openstack Swift might have worked, too, if it hadn't been HTTP only.