Storage object - NFS
alessandro.garbelli@corsinvest.it
2 Posts
October 4, 2018, 9:16 pmQuote from alessandro.garbelli@corsinvest.it on October 4, 2018, 9:16 pmGood morning,
first: great work!
second: is there any plans to add storage object (example S3) and NFS management?
Thanks,
best regards
Good morning,
first: great work!
second: is there any plans to add storage object (example S3) and NFS management?
Thanks,
best regards
admin
2,921 Posts
October 5, 2018, 9:44 amQuote from admin on October 5, 2018, 9:44 amYes in the longer term.
For short term our focus is on block storage, for version 2.3/2.4 we will be adding block level backups, snapshots, geo-replication.
Thanks for the comment 🙂
Yes in the longer term.
For short term our focus is on block storage, for version 2.3/2.4 we will be adding block level backups, snapshots, geo-replication.
Thanks for the comment 🙂
Shiori
86 Posts
June 6, 2019, 2:11 amQuote from Shiori on June 6, 2019, 2:11 amWhy would you want file level storage on a block level system? That goes against what these technologies are supposed to do. It is best to treat PetaSAN as a directly attached hard disk, no different than the hard disks in your desktop/server. NFS is best treated as connecting to another desktop computer's hard disk, not exactly the same ideologies
Now do not get me wrong, we use NFS for an ISO repository for our Xenserver cluster and provide Samba to expose a company file store. How we do it is a bit different from what you indicated though, instead of trying to get a block device (PetaSAN) to expose NFS and Samba targets we use a small "server" to attach to an iSCSI disk and then expose that as both an NFS and Samba store. This works very well and allows us to make upgrades to the software without disturbing the actual data. Yes there is the complaint of yet one more box running, but without doing much more than acting as a gateway this could run on a RaspberryPI without taxing it too much. Due to a network type choice we are using an old Core2 duo desktop with 4GB ram and 64GB SD card to provide these services and we never come close to maxing it out, the point being not much horsepower is needed unless you are looking at hundreds of concurrent connections. This could be done on a VM too, but there is a major limitation of pre VM access hence why we have a dedicated box.
Why would you want file level storage on a block level system? That goes against what these technologies are supposed to do. It is best to treat PetaSAN as a directly attached hard disk, no different than the hard disks in your desktop/server. NFS is best treated as connecting to another desktop computer's hard disk, not exactly the same ideologies
Now do not get me wrong, we use NFS for an ISO repository for our Xenserver cluster and provide Samba to expose a company file store. How we do it is a bit different from what you indicated though, instead of trying to get a block device (PetaSAN) to expose NFS and Samba targets we use a small "server" to attach to an iSCSI disk and then expose that as both an NFS and Samba store. This works very well and allows us to make upgrades to the software without disturbing the actual data. Yes there is the complaint of yet one more box running, but without doing much more than acting as a gateway this could run on a RaspberryPI without taxing it too much. Due to a network type choice we are using an old Core2 duo desktop with 4GB ram and 64GB SD card to provide these services and we never come close to maxing it out, the point being not much horsepower is needed unless you are looking at hundreds of concurrent connections. This could be done on a VM too, but there is a major limitation of pre VM access hence why we have a dedicated box.
SmokinJoe
2 Posts
May 5, 2020, 9:10 pmQuote from SmokinJoe on May 5, 2020, 9:10 pm
Quote from Shiori on June 6, 2019, 2:11 am
Why would you want file level storage on a block level system?
Well in the VMware world it is dead simple to do NFS 4.1 and with session trunking we get to round robin all our sessions to make use of all interfaces when needed. iSCSI and VMware have a bunch of hoop jumping and if you reboot/crash/power loss and you have 1 iSCSI connection down you get to wait for VMware to time out. That is so much fun!
Thanks,
Joe
Quote from Shiori on June 6, 2019, 2:11 am
Why would you want file level storage on a block level system?
Well in the VMware world it is dead simple to do NFS 4.1 and with session trunking we get to round robin all our sessions to make use of all interfaces when needed. iSCSI and VMware have a bunch of hoop jumping and if you reboot/crash/power loss and you have 1 iSCSI connection down you get to wait for VMware to time out. That is so much fun!
Thanks,
Joe
Storage object - NFS
alessandro.garbelli@corsinvest.it
2 Posts
Quote from alessandro.garbelli@corsinvest.it on October 4, 2018, 9:16 pmGood morning,
first: great work!
second: is there any plans to add storage object (example S3) and NFS management?
Thanks,
best regards
Good morning,
first: great work!
second: is there any plans to add storage object (example S3) and NFS management?
Thanks,
best regards
admin
2,921 Posts
Quote from admin on October 5, 2018, 9:44 amYes in the longer term.
For short term our focus is on block storage, for version 2.3/2.4 we will be adding block level backups, snapshots, geo-replication.
Thanks for the comment 🙂
Yes in the longer term.
For short term our focus is on block storage, for version 2.3/2.4 we will be adding block level backups, snapshots, geo-replication.
Thanks for the comment 🙂
Shiori
86 Posts
Quote from Shiori on June 6, 2019, 2:11 amWhy would you want file level storage on a block level system? That goes against what these technologies are supposed to do. It is best to treat PetaSAN as a directly attached hard disk, no different than the hard disks in your desktop/server. NFS is best treated as connecting to another desktop computer's hard disk, not exactly the same ideologies
Now do not get me wrong, we use NFS for an ISO repository for our Xenserver cluster and provide Samba to expose a company file store. How we do it is a bit different from what you indicated though, instead of trying to get a block device (PetaSAN) to expose NFS and Samba targets we use a small "server" to attach to an iSCSI disk and then expose that as both an NFS and Samba store. This works very well and allows us to make upgrades to the software without disturbing the actual data. Yes there is the complaint of yet one more box running, but without doing much more than acting as a gateway this could run on a RaspberryPI without taxing it too much. Due to a network type choice we are using an old Core2 duo desktop with 4GB ram and 64GB SD card to provide these services and we never come close to maxing it out, the point being not much horsepower is needed unless you are looking at hundreds of concurrent connections. This could be done on a VM too, but there is a major limitation of pre VM access hence why we have a dedicated box.
Why would you want file level storage on a block level system? That goes against what these technologies are supposed to do. It is best to treat PetaSAN as a directly attached hard disk, no different than the hard disks in your desktop/server. NFS is best treated as connecting to another desktop computer's hard disk, not exactly the same ideologies
Now do not get me wrong, we use NFS for an ISO repository for our Xenserver cluster and provide Samba to expose a company file store. How we do it is a bit different from what you indicated though, instead of trying to get a block device (PetaSAN) to expose NFS and Samba targets we use a small "server" to attach to an iSCSI disk and then expose that as both an NFS and Samba store. This works very well and allows us to make upgrades to the software without disturbing the actual data. Yes there is the complaint of yet one more box running, but without doing much more than acting as a gateway this could run on a RaspberryPI without taxing it too much. Due to a network type choice we are using an old Core2 duo desktop with 4GB ram and 64GB SD card to provide these services and we never come close to maxing it out, the point being not much horsepower is needed unless you are looking at hundreds of concurrent connections. This could be done on a VM too, but there is a major limitation of pre VM access hence why we have a dedicated box.
SmokinJoe
2 Posts
Quote from SmokinJoe on May 5, 2020, 9:10 pmQuote from Shiori on June 6, 2019, 2:11 amWhy would you want file level storage on a block level system?
Well in the VMware world it is dead simple to do NFS 4.1 and with session trunking we get to round robin all our sessions to make use of all interfaces when needed. iSCSI and VMware have a bunch of hoop jumping and if you reboot/crash/power loss and you have 1 iSCSI connection down you get to wait for VMware to time out. That is so much fun!
Thanks,
Joe
Quote from Shiori on June 6, 2019, 2:11 am
Why would you want file level storage on a block level system?
Well in the VMware world it is dead simple to do NFS 4.1 and with session trunking we get to round robin all our sessions to make use of all interfaces when needed. iSCSI and VMware have a bunch of hoop jumping and if you reboot/crash/power loss and you have 1 iSCSI connection down you get to wait for VMware to time out. That is so much fun!
Thanks,
Joe