ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Someone doesn't like local storage for large amounts of data

    IT Discussion
    xenorchestra xo storage
    7
    65
    7.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stacksofplatesS
      stacksofplates @Dashrender
      last edited by

      @Dashrender

      Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

      Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

      scottalanmillerS 1 Reply Last reply Reply Quote 1
      • scottalanmillerS
        scottalanmiller @FATeknollogee
        last edited by

        @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

        @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

        No, the idea of putting local storage into files is a post-virtualization concept.

        1 Reply Last reply Reply Quote 0
        • stacksofplatesS
          stacksofplates @FATeknollogee
          last edited by stacksofplates

          @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

          @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

          You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

          scottalanmillerS J 2 Replies Last reply Reply Quote 1
          • scottalanmillerS
            scottalanmiller @stacksofplates
            last edited by

            @stacksofplates said in Someone doesn't like local storage for large amounts of data:

            @Dashrender

            Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

            Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

            Agreed. The problem that is being run into here is one of replication capacity and affects a NAS the same that affects a VM. So you solve both in the same way.

            In a VM, you turn to Gluster, et al. In physical you turn to Exablox or similar.

            stacksofplatesS 1 Reply Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @stacksofplates
              last edited by

              @stacksofplates said in Someone doesn't like local storage for large amounts of data:

              @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

              @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

              You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

              ANd we did, a lot, prior to virtualizing.

              stacksofplatesS 1 Reply Last reply Reply Quote 0
              • stacksofplatesS
                stacksofplates @scottalanmiller
                last edited by

                @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

                @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

                You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

                ANd we did, a lot, prior to virtualizing.

                Ya I still do for our workstations.

                1 Reply Last reply Reply Quote 0
                • stacksofplatesS
                  stacksofplates @scottalanmiller
                  last edited by

                  @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                  @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                  @Dashrender

                  Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

                  Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

                  Agreed. The problem that is being run into here is one of replication capacity and affects a NAS the same that affects a VM. So you solve both in the same way.

                  In a VM, you turn to Gluster, et al. In physical you turn to Exablox or similar.

                  We have two Isilons coming. One is here and ready to be installed. Much easier than managing all of that myself.

                  Our guys can generate about 20TB a week between them all.

                  scottalanmillerS J 2 Replies Last reply Reply Quote 0
                  • scottalanmillerS
                    scottalanmiller @stacksofplates
                    last edited by

                    @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                    @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                    @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                    @Dashrender

                    Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

                    Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

                    Agreed. The problem that is being run into here is one of replication capacity and affects a NAS the same that affects a VM. So you solve both in the same way.

                    In a VM, you turn to Gluster, et al. In physical you turn to Exablox or similar.

                    We have two Isilons coming. One is here and ready to be installed. Much easier than managing all of that myself.

                    Our guys can generate about 20TB a week between them all.

                    Looked at Isilon a bit a few weeks ago. Definitely nice gear there.

                    stacksofplatesS 1 Reply Last reply Reply Quote 1
                    • stacksofplatesS
                      stacksofplates @scottalanmiller
                      last edited by

                      @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                      @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                      @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                      @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                      @Dashrender

                      Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

                      Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

                      Agreed. The problem that is being run into here is one of replication capacity and affects a NAS the same that affects a VM. So you solve both in the same way.

                      In a VM, you turn to Gluster, et al. In physical you turn to Exablox or similar.

                      We have two Isilons coming. One is here and ready to be installed. Much easier than managing all of that myself.

                      Our guys can generate about 20TB a week between them all.

                      Looked at Isilon a bit a few weeks ago. Definitely nice gear there.

                      For the price it should be.

                      scottalanmillerS 1 Reply Last reply Reply Quote 0
                      • scottalanmillerS
                        scottalanmiller @stacksofplates
                        last edited by

                        @stacksofplates Oh yeah, we didn't go with it, not cost effective at all. The price was a bit crazy.

                        stacksofplatesS 1 Reply Last reply Reply Quote 0
                        • stacksofplatesS
                          stacksofplates @scottalanmiller
                          last edited by stacksofplates

                          @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                          @stacksofplates Oh yeah, we didn't go with it, not cost effective at all. The price was a bit crazy.

                          We shaved it down a bit by supplying our own rack, power cables, PDU, etc. They tried to throw all of that in the quote.

                          Power cables at ~$60 a piece adds up.

                          1 Reply Last reply Reply Quote 1
                          • J
                            Jason Banned @stacksofplates
                            last edited by

                            @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                            @scottalanmiller said in Someone doesn't like local storage for large amounts of data:

                            @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                            @Dashrender

                            Dustin would still need/want to CR that host to another host allowing him to spin up that data very quickly in the case of a failure.

                            Use tools built for that. GFS2, Gluster, Ceph, Swift, Cinder, etc. The VM would remount after booting in the new host and the storage still fails over.

                            Agreed. The problem that is being run into here is one of replication capacity and affects a NAS the same that affects a VM. So you solve both in the same way.

                            In a VM, you turn to Gluster, et al. In physical you turn to Exablox or similar.

                            We have two Isilons coming. One is here and ready to be installed. Much easier than managing all of that myself.

                            Our guys can generate about 20TB a week between them all.

                            There pretty nice. We'd gotten Demo units. We use the VMAX though.

                            1 Reply Last reply Reply Quote 1
                            • J
                              Jason Banned @stacksofplates
                              last edited by

                              @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                              @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

                              @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

                              You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

                              @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                              @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

                              @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

                              You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

                              RAWs biggest limitation is you can't storage vmotion it. You can vmotion the pointer but if you are retiring a SAN or something you will be doing it manually.

                              stacksofplatesS 1 Reply Last reply Reply Quote 2
                              • stacksofplatesS
                                stacksofplates @Jason
                                last edited by

                                @Jason said in Someone doesn't like local storage for large amounts of data:

                                @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                                @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

                                @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

                                You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

                                @stacksofplates said in Someone doesn't like local storage for large amounts of data:

                                @FATeknollogee said in Someone doesn't like local storage for large amounts of data:

                                @scottalanmiller Isn't that part of why we all virtualize so we don't have deal with raw?

                                You can still snapshot raw. Raw can be an image file or a volume or a full disk. Raw doesn't mean not virtualized.

                                RAWs biggest limitation is you can't storage vmotion it. You can vmotion the pointer but if you are retiring a SAN or something you will be doing it manually.

                                Ya I'm using KVM so I can either move the raw file or the volume to wherever I need it. It's really simple with qemu and lvm.

                                1 Reply Last reply Reply Quote 1
                                • 1
                                • 2
                                • 3
                                • 4
                                • 3 / 4
                                • First post
                                  Last post