First sketches of the new BeaST Grid family storage system

“The BeaST Grid” is a work name of the reliable storage cluster concept. It will consist of a few Controller Nodes with optional internal drives and several Drive only Nodes. All nodes are commodity computers with internal drives.

Controller Nodes will also be able to work in driveless, standalone mode and therefore may be used as storage virtualizators for other storage systems.

First version of the BeaST Grid will be based on the BeaST Classic with RAID system.

Advertisements

About mezzantrop

10 years of experience in large SAN and storage environments: mainly Hitachi, HP and Brocade. Now I am a proud SAN/storage IBMer. Empty – expect-like tool author. FreeBSD enthusiast.
This entry was posted in BeaST, My projects, Storage and tagged , , , , , , . Bookmark the permalink.

2 Responses to First sketches of the new BeaST Grid family storage system

  1. asg2ki says:

    Hey Mikhail,

    While I’m occasionally following your blog regarding the BeaST project you are working on, I came across few technical questions regarding the latest sketch. I hope you can provide me with some more details on this project as I’m very interested to test out few things myself in my home lab.

    Just a little background for you, I’ve been testing numerous concepts for HA based storage systems for my own needs (obviously I don’t want to host an enterprise SAN at home although I used to in the past), but unfortunately all properly working solutions are falling into the paid expensive categories, so for the time being I’m still stuck with a single node ZFS based storage system. I’ve been testing out storage concepts under various OS’s and so far the most stable I could think of is BSD. Furthermore when it comes to data storage, I prefer to rely primarily on ZFS due to its redundancy, performance and flexibility features.

    The BeaST concept looks really good in theory and right now it reminds me a bit of PetaSAN considering how the BeaST’s controller node would actually play an “iSCSI” gateway role between the storage pools and the client initiators. With the current drawing I’m a bit confused about the right side of the picture where the ZFS pools are held, so what I’m trying to understand is if we are explicitly talking about the controller and storage nodes being separate machines or if those ZFS pools could be part of the individual controller nodes where the iSCSI initiator and target would be handled internally via private connections. My confusion comes from the fact that on the controller nodes (middle of the picture) you are showing RAID5 arrays which consist supposedly from several ZVOL’s hosted on external machines but correct me if I’m wrong. Also I suppose on the controller nodes we are talking about BSD raid solution for the volumes instead of ZFS.

    As far as I can understand the main problem is still with failovering ZFS pools between physical hosts. I’ve been fighting this too for a looooong time without success or at least not without some sort of data corruption, and one of the biggest problems by trying a typical ZFS export/import was with the automation. Literally every non-paid “solution” to this is a piece of crap and here I’m not even speaking about cross compatibility between various software components involved in such approaches. Other approaches which would involve replication between two or more storage nodes would simply defeat the purpose of using the ZFS redundancy and therefore effectively lose storage space potential.

    So all in all regarding your sketch if I’m right about the storage and controller nodes being separated I consider this methodology as a workaround to the ZFS failover but again feel free to correct me in case I misunderstood something. By the way I see some “Sequoia Lustre” similarities in the current design :).

    Anyway I would appreciate if you could provide me with few more technical details on your concept. I still hope that some day someone would craft an enterprise-grade stable HA storage solution and release it to the public but for the time being I can just dream 🙂

    Thanks & Regards

    Liked by 1 person

    • mezzantrop says:

      Hi, asg2ki!

      First of all, nice to meet you and thank you for your interest in the BeaST subject. Regarding the architecture, the “BeaST Grid” consists of the “controller nodes” on the left which will work, as you say, like gateways to the “drive nodes” on the right side, where both controller nodes and drive nodes are computers running FreeBSD OS. As for initial work I took ZFS on drive nodes and I had to limit controller configuration with GEOM RAID, because of failover issues with ZFS, also already mentioned by you. So you see the situation very clear.

      I have played with ZFS-failower on the “BeaST Classic” version which is supposed to be “monolithic” storage configuration with “controllers” and plain “physical drive enclosures”, and I have partially succeeded in it. You can read the full story, as well as step by step guides to reproduce all configurations on the BeaST project page where I’m trying to keep all my working papers for the subject.

      Keep in mind, all my test lab is actually a bunch of Virtualbox virtual machines on my laptop, so this is pretty much theoretical project for now.

      Sure, I will answer your further questions with a great pleasure, if I have enough knowledge to do that 🙂

      Best regards,
      Mike

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s