{"id":995,"date":"2016-11-16T13:04:50","date_gmt":"2016-11-16T18:04:50","guid":{"rendered":"http:\/\/www.smbitjournal.com\/?p=995"},"modified":"2017-02-19T05:01:50","modified_gmt":"2017-02-19T10:01:50","slug":"new-hyperconvergence-old-storage","status":"publish","type":"post","link":"https:\/\/smbitjournal.com\/2016\/11\/new-hyperconvergence-old-storage\/","title":{"rendered":"New Hyperconvergence, Old Storage"},"content":{"rendered":"

We all dream of the day that we get to build a new infrastructure from the ground up without any existing technical debt to hold us back.\u00a0 A greenfield deployment where we pick what is best, roll it out fresh and enjoy.\u00a0 But most of us live in the real world where that is not very realistic and what we actually face is a world where we have to plan for the future but work with what we already have, as well.<\/p>\n

Making do with what we have is nearly an inevitable fact of life in IT and when approaching storage when moving from an existing architecture to hyperconvergence things will be no different.\u00a0 In a great many cases we will be facing a situation where an existing investment in storage will be in place that we do not want to simply discard but does not necessarily fit neatly into our vision of a hyperconverged future.<\/p>\n

There are obvious options to consider, of course, such as returning leased gear, retiring older equipment or selling still useful equipment outright.\u00a0 These are viable options and should be considered.\u00a0 Eliminating old gear or equipment that does not fit well into the current plans can be beneficial as we can simplify our networks, reduce power consumption and possible even recoup some degree of our investments.<\/p>\n

In reality, however, these options are rarely financially viable and we need to make more productive use of our existing technology investments.\u00a0 What options are available to us, of course, depend on a range of factors.\u00a0 But we will look at some examples of how common storage devices can be re-purposed in a new hyperconverged-based system in order to maintain their utility either until they are ready to retire or even, in some cases, indefinitely.<\/p>\n

The easiest re-purposing of existing storage, and this applies equally to both NAS and SAN in most cases, is to designate them as backup or archival targets.\u00a0 Traditional NAS and SAN devices are excellent backup hardware and are generally usable by nearly any backup mechanism, regardless of approach or vendor.\u00a0 And because they are generic backup targets if a mixture of backup mechanisms are used, such as agent based, agentless and custom scripts, these can all work to the same target.\u00a0 Backups so rarely get the attention and investment that they deserve that this is not just the easiest but often the most valuable use of pre-existing storage infrastructure.<\/p>\n

Of course anything that is appropriate for backups can also be used for archival storage.\u00a0 Archival needs are generally less needed (only a percentage of firms need archival storage while all need backups) and are of lower priority, so this is more of an edge reuse case, but still one to consider, especially for organizations that may be working to re-purpose a large number of possibly disparate storage devices.\u00a0 However it is worth noting that moving to hyperconvergence does tend to “flatten” the compute and storage space in a way that may easily introduce a value to lower performance, lower priority archival storage that may not have existed or existed so obviously prior to the rearchitecting of the environment.<\/p>\n

NAS has the unique advantageous use cases of being usable as general purpose network storage, especially for home directories of end users.\u00a0 NAS storage can be used in so many places on the network, it is very easy to continue to use, after moving core architectures.\u00a0 The most popular case is for users’ own storage needs with the NAS connected directly to end user devices which allows for storage capacity, performance and network traffic to be offloaded from the converged infrastructure to the NAS.\u00a0\u00a0\u00a0 It would actually be very rare to remove a NAS from a hyperconverged network as its potential utility is so high and apparent.<\/p>\n

Both SAN and NAS have the potential to be attached directly to the virtual machines running on top of a hyperconverged infrastructure as well.\u00a0 In this way they can continue to be utilized in a traditional manner until such time as they are no longer needed or appropriate.\u00a0 While not often the recommended approach, attaching network storage to a VM directly, there are use cases for this and it allows systems to behave as they always have in a physical realm into the future.\u00a0 This is especially useful for mapped drives and user directories via a NAS, much as we mentioned for end user devices, but the cases are certainly not limited to this.<\/p>\n

A SAN can provide some much needed functionality in some cases for certain workloads that require shared block storage that otherwise is not available or exposed on a platform.\u00a0 Workloads on a VM will use the SAN as they always have and not even be aware that they are virtualized or converged.\u00a0 Of course we can also attach a SAN to a virtualized file server or NAS head running on our hyperconverged infrastructure if the tiering for that kind of workload is deemed appropriate as well.<\/p>\n

Working with existing infrastructure when implementing a new one does present a challenge, but one that we can tackle with creativity and logical approach.\u00a0 Storage is a nearly endless challenge and having existing storage to re-purpose may easily end up being exceptionally advantageous.<\/p>\n","protected":false},"excerpt":{"rendered":"

We all dream of the day that we get to build a new infrastructure from the ground up without any existing technical debt to hold us back.\u00a0 A greenfield deployment where we pick what is best, roll it out fresh and enjoy.\u00a0 But most of us live in the real world where that is not … Continue reading New Hyperconvergence, Old Storage<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[238,41],"tags":[48,32],"class_list":["post-995","post","type-post","status-publish","format-standard","hentry","category-hyperconvergence","category-storage-2","tag-nas","tag-san"],"_links":{"self":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/995","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/comments?post=995"}],"version-history":[{"count":1,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/995\/revisions"}],"predecessor-version":[{"id":996,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/995\/revisions\/996"}],"wp:attachment":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/media?parent=995"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/categories?post=995"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/tags?post=995"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}