{"id":6309,"date":"2017-06-05T07:59:06","date_gmt":"2017-06-04T21:59:06","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=6309"},"modified":"2018-12-11T08:37:03","modified_gmt":"2018-12-10T22:37:03","slug":"architecture-matters-protection-in-the-cloud-part-2","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2017\/06\/05\/architecture-matters-protection-in-the-cloud-part-2\/","title":{"rendered":"Architecture Matters: Protection in the Cloud (Part 2)"},"content":{"rendered":"<p>(<a href=\"https:\/\/nsrd.info\/blog\/2017\/05\/23\/architecture-matters-protection-in-the-cloud-part-1\/\" target=\"_blank\" rel=\"noopener noreferrer\">Part 1<\/a>).<\/p>\n<p>Particularly when we think of IaaS style workloads in the Cloud, there&#8217;s two key approaches that can be used for data protection.<\/p>\n<p>The first is snapshots.&nbsp;Snapshots fulfil part of a data protection strategy, but we do always need to remember with snapshots that:<\/p>\n<ul>\n<li>They&#8217;re an inefficient storage and retrieval model for long-term retention<\/li>\n<li>Cloud or not, they&#8217;re still essentially on-platform<\/li>\n<\/ul>\n<p>As we know, and something I cover in my book quite a bit \u2013&nbsp;<a href=\"https:\/\/www.amazon.com\/Data-Protection-Ensuring-Availability\/dp\/1482244152\/ref=mt_paperback?_encoding=UTF8&amp;me=\" target=\"_blank\" rel=\"noopener noreferrer\">a real data&nbsp;protection strategy&nbsp;will be multi-layered<\/a>. Snapshots undoubtedly can provide options around meeting fast RTOs and minimal RPOs, but&nbsp;traditional backup systems will deliver a sufficient recovery granularity for&nbsp;protection copies stretching back weeks, months or years.<\/p>\n<p>Stepping back from data&nbsp;protection itself \u2013 public cloud is a very different operating model to traditional&nbsp;&nbsp;in-datacentre infrastructure spending. The classic in-datacentre&nbsp;infrastructure procurement process is an up-front investment designed around 3- or 5-year depreciation schedules. For some businesses that may mean a literal up-front purchase to cover the entire time-frame (particularly so when infrastructure budget is only released for the initial deployment project), and for others with more fluid budget options, there&#8217;ll be an investment into infrastructure that can be expanded over the 3- or 5-year solution lifetime to meet systems growth.<\/p>\n<p>Cloud \u2013 public Cloud \u2013 isn&#8217;t costed or sold that way. It&#8217;s a much smaller&nbsp;billing window and costing model; use a GB or RAM, pay for a GB of RAM. Use a GHz or CPU, pay for a GHz of CPU. Use a GB of&nbsp;storage, pay for a GB of storage. Public cloud&nbsp;costing models often remind me of <a href=\"https:\/\/www.youtube.com\/watch?v=aTZYSzxZcvA\" target=\"_blank\" rel=\"noopener noreferrer\">Master of the House<\/a> from Les Miserables, particularly this verse:<\/p>\n<blockquote><p>Charge &#8217;em for the lice, extra for the mice<br \/>\nTwo percent for looking in the mirror twice<br \/>\nHere a little slice, there a little cut<br \/>\nThree percent for sleeping with the window shut<br \/>\nWhen it comes to fixing prices<br \/>\nThere are a lot of tricks I knows<br \/>\nHow it all increases, all them bits and pieces<br \/>\nJesus! It&#8217;s amazing how it grows!<\/p>\n<p>Master&nbsp;of the House, Les Miserables.<\/p><\/blockquote>\n<p>That&#8217;s the Cloud operating model in a nutshell.&nbsp;Minimal (or no) up-front investment, but you pay for every scintilla of resource you use \u2013 every day or month.<\/p>\n<p>If you say, deploy a $30,000 server into your datacentre, you then get to use that as much or as little as you want, without any further costs beyond power and cooling*. With Cloud, you won&#8217;t be paying&nbsp;that $30,000 initial fee, but you will pay for every MHz, KB of RAM and byte of storage consumed within every billing period.<\/p>\n<p>If you want Cloud to be cost-effective,&nbsp;you have to be able to optimise \u2013 you have to effectively&nbsp;<em>game<\/em> the system, so to speak. Your in-Cloud services have to be&nbsp;<em>maximally streamlined<\/em>. We&#8217;ve become inured to resource wastage in the datacentre because resources have been cheap for a long time. RAM size\/speed grows, CPU speed grows, as does the number of cores, and storage \u2013 well, storage seems to have an&nbsp;infinite expansion capability. Who cares if what you&#8217;re doing generates 5 TB of logs per day? Information is money, after all.<\/p>\n<p>To me, this is just the next step in&nbsp;the somewhat lost art of programmatic optimisation. I grew up in the days of 8-bit computing**, and we knew back then that CPU, RAM and storage <em>weren&#8217;t<\/em> infinite. This didn&#8217;t end with 8-bit computing, though.&nbsp;When I started in IT as a Unix system administrator, swap file sizing, layout and performance was something that formed a critical aspect of your overall configuration, because if \u2013 Jupiter forbid \u2013 your system started swapping, you needed a fighting chance that the swapping wasn&#8217;t going to kill your performance. Swap file optimisation was, to use a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Bianca_Del_Rio\" target=\"_blank\" rel=\"noopener noreferrer\">Bianca Del Rio<\/a>&nbsp;line, all about the goal: &#8220;Not today, Satan.&#8221;<\/p>\n<p>That&#8217;s&nbsp;Cloud, now. But we&#8217;re not so much talking about&nbsp;swap files as we are resource consumption. Optimisation is critical. A failure to optimise means you&#8217;ll pay more. The only time you want to pay more is when what you&#8217;re paying for delivers a tangible, cost-recoverable benefit to the business. (I.e., it&#8217;s something you get to charge someone else for, either immediately, or later.)<\/p>\n<p><a href=\"https:\/\/nsrd.info\/blog\/2017\/06\/05\/architecture-matters-protection-in-the-cloud-part-2\/bigstock-cloud-cost\/\" rel=\"attachment wp-att-6311\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-6311\" src=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/bigstock-Cloud-Cost.jpg\" alt=\"Cloud Cost\" width=\"900\" height=\"506\" srcset=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/bigstock-Cloud-Cost.jpg 900w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/bigstock-Cloud-Cost-300x169.jpg 300w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/bigstock-Cloud-Cost-768x432.jpg 768w\" sizes=\"auto, (max-width: 900px) 100vw, 900px\" \/><\/a><\/p>\n<p>If we think about backup, it&#8217;s about getting data from location A to location B.&nbsp;In order to optimise it, you want to do two distinct thinks:<\/p>\n<ul>\n<li>Minimise the number of &#8216;hops&#8217; that data has to make in order to get from A to B<\/li>\n<li>Minimise the amount of data that you need to send from A to B.<\/li>\n<\/ul>\n<p>If you don&#8217;t optimise that, you end up in a &#8216;classic&#8217;&nbsp;backup architecture that we&nbsp;used to rely so much on in the 90s and early 00s, such as:<\/p>\n<p><a href=\"https:\/\/nsrd.info\/blog\/2017\/06\/05\/architecture-matters-protection-in-the-cloud-part-2\/cloud-architecture-matters-1\/\" rel=\"attachment wp-att-6312\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-6312\" src=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1.jpg\" alt=\"Cloud Architecture Matters 1\" width=\"1139\" height=\"1197\" srcset=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1.jpg 1139w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1-285x300.jpg 285w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1-768x807.jpg 768w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1-974x1024.jpg 974w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-1-24x24.jpg 24w\" sizes=\"auto, (max-width: 1139px) 100vw, 1139px\" \/><\/a><\/p>\n<p>(In this case I&#8217;m looking just at backup services that land data into object storage.&nbsp;There are situations where you might want higher performance than what object offers, but let&#8217;s stick just with object storage for&nbsp;the time being.)<\/p>\n<p>I don&#8217;t think this diagram is actually good at giving the full picture. There&#8217;s another way I like to draw the diagram, and it looks like this:<\/p>\n<p><a href=\"https:\/\/nsrd.info\/blog\/2017\/06\/05\/architecture-matters-protection-in-the-cloud-part-2\/cloud-architecture-matters-2\/\" rel=\"attachment wp-att-6313\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-6313\" src=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2.jpg\" alt=\"Cloud Architecture Matters 2\" width=\"1139\" height=\"1197\" srcset=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2.jpg 1139w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2-285x300.jpg 285w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2-768x807.jpg 768w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2-974x1024.jpg 974w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/06\/Cloud-Architecture-Matters-2-24x24.jpg 24w\" sizes=\"auto, (max-width: 1139px) 100vw, 1139px\" \/><\/a><\/p>\n<p>In the Cloud, you&#8217;re going to pay for the systems you&#8217;re running for business purposes no matter&nbsp;what. That&#8217;s a cost you have&nbsp;to accept, and the goal is to ensure that whatever services or products you&#8217;re&nbsp;<em>on-selling<\/em> to <em>your<\/em> customers using those services will pay for the running costs in the Cloud***.<\/p>\n<p>You want to ensure you can protect data in the Cloud, but sticking to architectures designed at the time of on-premises infrastructure \u2013 and&nbsp;<em>physical<\/em> infrastructure at that \u2013 is&nbsp;significantly sub-optimal.<\/p>\n<p>Think&nbsp;of how traditional media servers (or in NetWorker parlance, storage nodes) needed to work.&nbsp;A media server&nbsp;is designed to be a high performance&nbsp;system that funnels data coming&nbsp;from client to protection storage.&nbsp;If a backup architecture still&nbsp;heavily&nbsp;relies on media servers, then the cost in the&nbsp;Cloud is going to be higher than you need it \u2013 or want it \u2013 to be. That gets worse if a media server needs to be some sort of&nbsp;highly specced&nbsp;system encapsulating&nbsp;non-optimised&nbsp;deduplication. For instance, one of NetWorker&#8217;s competitors provides details on their website of hardware requirements for deduplication media servers, so I&#8217;ve taken these specifications directly from their website. To work with just 200 TB of&nbsp;storage allocated for deduplication, a&nbsp;media server for that&nbsp;product needs:<\/p>\n<ul>\n<li>16 CPU Cores<\/li>\n<li>128 GB of RAM<\/li>\n<li>400 GB&nbsp;SSD for OS and applications<\/li>\n<li>2 TB of SSD for deduplication databases<\/li>\n<li>2 TB of 800 IOPs+ disk (SSD recommended in some instances) for index cache<\/li>\n<\/ul>\n<p>For every 200 TB. Think on that for a moment. If you&#8217;re deploying systems in&nbsp;the Cloud that&nbsp;generate a lot of data, you could very easily find yourself having to deploy&nbsp;<em>multiple<\/em> systems such as the above to protect those workloads, in&nbsp;addition to the backup server itself and the protection storage that underpins the deduplication system.<\/p>\n<p>Or, on the other hand, you could&nbsp;work with an efficient architecture designed to minimise the number of data hops, and minimise the amount of data transferred:<\/p>\n<p><a href=\"https:\/\/nsrd.info\/blog\/2017\/01\/13\/cloud-boost-vs-cloud-tier\/cloudboost-2\/\" rel=\"attachment wp-att-6120\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-6120\" src=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/01\/CloudBoost.jpg\" alt=\"CloudBoost Workflow\" width=\"1616\" height=\"1804\" srcset=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/01\/CloudBoost.jpg 1616w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/01\/CloudBoost-269x300.jpg 269w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/01\/CloudBoost-768x857.jpg 768w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/01\/CloudBoost-917x1024.jpg 917w\" sizes=\"auto, (max-width: 1616px) 100vw, 1616px\" \/><\/a><\/p>\n<p>That&#8217;s NetWorker with CloudBoost.&nbsp;Unlike that competitor, a single CloudBoost appliance doesn&#8217;t just&nbsp;allow you&nbsp;to address&nbsp;200TB of deduplication storage, but 6 PB of logical&nbsp;object storage. <strong>6 PB, <\/strong>not<strong> 200 TB<\/strong>. All that using 4 \u2013 8 CPUs and 16 \u2013 32GB of RAM, and with a&nbsp;metadata sizing ratio of 1:2000 (i.e., every 100 GB of metadata&nbsp;storage allows you to address 200 TB of logical capacity). Yes, there&#8217;ll be SSD optimally for the metadata, but&nbsp;noticeably less than the&nbsp;competitor&#8217;s media server \u2013 and with a significantly greater addressable range.<\/p>\n<p>NetWorker and CloudBoost can do that because the deduplication workflow has been optimised. In much the same way that NetWorker and Data Domain work together, within a CloudBoost environment, NetWorker clients will participate in the segmentation, deduplication, compression (and encryption!) of the data. That&#8217;s the&nbsp;first&nbsp;architectural advantage: rather than needing a big server to handle&nbsp;all&nbsp;the&nbsp;deduplication of&nbsp;the protection environment, a little bit of load is leveraged in each client being protected. The second architectural advantage&nbsp;is that the CloudBoost appliance&nbsp;<em>does&nbsp;not pass the data through<\/em>. Clients send their&nbsp;deduplicated,&nbsp;compressed and encrypted data&nbsp;<em>directly<\/em> to the object storage, minimising the data hops involved****.<\/p>\n<p>To be sure, there are still going to be costs associated with running a NetWorker+CloudBoost configuration in public cloud \u2013 but that will be true of any data protection service. That&#8217;s the nature&nbsp;of public cloud \u2013 you use it, you pay for it. What you&nbsp;<em>do<\/em> get with NetWorker+CloudBoost though is one of the most&nbsp;streamlined and optimised public cloud backup options&nbsp;available. In an infrastructure model where you pay for every resource consumed,&nbsp;it&#8217;s imperative that the backup architecture be as resource-optimised as possible.<\/p>\n<p>IaaS workloads&nbsp;will&nbsp;only continue to grow in public cloud. If&nbsp;your business uses NetWorker, you can&nbsp;take comfort in being able to still protect those workloads while they&#8217;re in public cloud, and doing it efficiently, optimised for maximum storage potential with minimised resource cost. Remember always: architecture matters, no matter where your infrastructure is.<\/p>\n<hr>\n<p>Hey, if you found this useful, don&#8217;t forget to check out <a href=\"https:\/\/www.amazon.com\/Data-Protection-Ensuring-Availability\/dp\/1482244152\" target=\"_blank\" rel=\"noopener noreferrer\">Data Protection:&nbsp;Ensuring Data Availability<\/a>.<\/p>\n<hr>\n<p>&nbsp;<\/p>\n<p>&#8212;<br \/>\n* Yes, I am aware there&#8217;ll be other&nbsp;costs beyond power and cooling when calculating a true system management price, but I&#8217;m not going to go into those for the purposes of this blog.<\/p>\n<p>** Some readers of my blog may very well recall earlier computing models. But I started with a Vic-20,&nbsp;then the Commodore-64, and both taught me valuable lessons about what you can \u2013 and can&#8217;t \u2013 fit in memory.<\/p>\n<p>*** Many a company has been burnt by failing to&nbsp;cost that simple factor,&nbsp;but in the style of Michael Ende, that is another story, for another time.<\/p>\n<p>****&nbsp;Linux 64-bit clients do this now. Windows 64-bit clients&nbsp;are supported in NetWorker 9.2, coming soon. (In the interim Windows clients work via a storage node.)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>(Part 1). Particularly when we think of IaaS style workloads in the Cloud, there&#8217;s two key approaches that can be&hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[3],"tags":[230,301,1365,1364,770],"class_list":["post-6309","post","type-post","status-publish","format-standard","hentry","category-architecture","tag-cloud","tag-deduplication","tag-distributed-deduplication","tag-iaas","tag-public-cloud"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1DL","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=6309"}],"version-history":[{"count":9,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6309\/revisions"}],"predecessor-version":[{"id":7385,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/6309\/revisions\/7385"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=6309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=6309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=6309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}