存储效率，数据减少和压缩性能

  • 2017年5月18日
  • 2回答
  • 2599次观看
C
秩
UserLevel 3.
徽章 +14
  • 切 Nutanix员工
  • Nutanix员工
  • 8回复
Nutanix技术营销工程师Andy Daniel最近写了一篇简短的文章，概述了包括压缩在内的存储效率特性。在您的环境(Nutanix或其他)中，分享您为不同的工作负载所做的工作。

-
为了优化存储容量并加速应用性能，雅典卫城分布式存储结构使用数据效率技术，例如重复数据删除，压缩和擦除编码。它们是智能和适应性，在大多数情况下，需要很少或没有微调。实际上，在新的运输集群上默认情况下，可以与冷数据分类结合使用两个级别的后处理后压缩。因为它们完全驱动软件，它也意味着现有客户可以通过升级AOS来利用新功能和增强功能。

DSF提供内联压缩和后处理压缩，以最大化容量。很多时候，客户错误地将压缩与性能下降联系在一起，但对于Nutanix来说，情况并非如此。事实上，从AOS 5.0开始，所有随机写操作在被写入OpLog(写缓存)之前都被内联压缩，无论选择的配置是什么。压缩所增加的Oplog空间利用率改善了对持续随机写的突发处理，并允许在更长的时间内吸收持续随机写。

大型和顺序读取和写入也会看到压缩中的性能效益，因此在内联压缩（压缩延迟= 0）不合适的工作负载很少。它甚至建议用于Tier-1工作负载，例如Oracle，Microsoft SQL Server和Exchange。内联压缩另外提高容量层（范围存储）内的性能，同时最大限度地提高可用存储容量。

有了潜在的显著性能改进和显著增加集群有效存储容量的能力，现在没有理由不启用容器压缩!
    \n
    \n--
    \nTo optimize storage capacity and accelerate application performance, the Acropolis Distributed Storage Fabric uses data efficiency techniques such as deduplication, compression, and erasure coding. They are intelligent & adaptive, and in most cases, require little or no fine-tuning. In fact, two levels of post-process compression are enabled in conjunction with cold data classification by default on new shipping clusters. Because they\u2019re entirely software driven, it also means existing customers can take advantage of new capabilities and enhancements by upgrading AOS.
    \n
    \nDSF provides both inline and post-process compression to maximize capacity. Many times, customers incorrectly associate compression with reduced performance, but this isn\u2019t the case with Nutanix. In fact, as of AOS 5.0, all random writes are compressed inline before being written to OpLog (write cache), no matter the chosen configuration. Increased Oplog space utilization as the result of compression improves burst handling for sustained random writes and allows absorption of sustained random writes for a longer duration.
    \n
    \nLarge and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn\u2019t appropriate. It\u2019s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity.
    \n
    \nWith potentially dramatic performance improvements and the ability to significantly increase your cluster\u2019s effective storage capacity, there\u2019s no reason you shouldn\u2019t enable compression on your containers today!","quoteUsername":"chheda","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

    2回答

    nsegalle
    徽章 +2
    我对这个陈述感到困惑 - -

    "Large and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn’t appropriate. It’s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity."

    该声明似乎是直接的矛盾 - - -

    “压缩最佳实践” - - https://portal.nutanix.com/#/page/docs/details?targetid=web_console_guide-prism_v4_7:sto_compression_c.html - - -

    压缩数据的计算成本较高，而解压缩数据的计算成本较低。从这个事实可以得出这样的结论:数据只写入一次就经常读取的工作负载(比如用户数据存储)最适合压缩。这类工作负载的例子包括文件服务器、归档和备份。
    因为无法进一步压缩压缩数据，所以试图这样做，因此不会消耗系统资源，无益。既不是具有本质压缩数据（如JPEG或MPEG）的用户数据都不应该在具有本机压缩（如SQL Server或Oracle数据库）上的系统中的数据应该存储在压缩容器上。“

    虽然它是模棱两可的，因为你可能也可能不利用SQL压缩，但似乎有一个带走 - 压缩数据是计算昂贵的。我最近一直在研究这个主题，因为我们有一个在单个主机上运行的SQL服务器，它是占据整个节点（896GB RAM / 20 VCPU）的怪物VM，我们将注意到这主机的争用CVM。这主要是一个我们抛出硬件的应用程序问题，但由于我们将其移出了使用SSD SAN的HPE环境，我们开始注意到磁盘上的更高和更高的延迟，因为它已被移动到Nutanix。。Nutanix推荐我们启用内联压缩，这是大约6个月前完成的，但现在我们有一个CVM飙升CPU并经常以100％运行。我们计划为CVM提供更多VCPU，但我想知道我们是否要禁用内联压缩，我们会在这次主机上看到CVM的争用较少？想法？
    \r\n
    \r\n\"Large and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn\u2019t appropriate. It\u2019s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity.\"<\/i>
    \r\n
    \r\nThis statement seems to be a direct contradiction to - -
    \r\n
    \r\n\"Compression Best Practices\" - - https:\/\/portal.nutanix.com\/#\/page\/docs\/details?targetId=Web_Console_Guide-Prism_v4_7:sto_compression_c.html - -
    \r\n
    \r\n\"Compressing data is computationally expensive, while decompressing data is less so. From this fact it follows that workloads where data is written once and read frequently, such as user data storage, are most suitable for compression. Examples of such workloads are file servers, archiving, and backup.<\/i>
    \r\nBecause compressed data cannot be compressed further, attempting to do so consumes system resources for no benefit. Neither user data that comprises mainly natively compressed data (such as JPEG or MPEG) nor data in a system that has native compression (such as SQL Server or Oracle databases) should be stored on a compressed container.\"<\/i>
    \r\n
    \r\nAlthough it's ambiguous because you may or may not be utilizing compression on SQL, but it seems there is one take away - compressing data is computationally expensive. I have been researching this topic lately because we have a SQL server that is running on a single host, which is a monster VM taking up an entire node (896GB RAM\/20 vCPU), and we're noticing contention on this host with the CVM. This is mostly an application problem that we're throwing hardware at, but since we've moved it off of out HPE environment which utilized SSD SAN, we're starting to notice higher and higher latency on the disks since it's been moved to Nutanix. Nutanix recommended we enable inline compression, which was done about 6 months ago, but now we have a CVM who is spiking CPU and often running at 100%. We plan to give the CVM even more vCPUs, but I'm wondering if we were to disable inline compression we'd see less contention of the CVM on this host? Thoughts?","quoteUsername":"nsegalle","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    欢的
    徽章
    在运行大型SQL数据仓库，Nutanix或Native SQL 2016时，是否有人对哪个压缩是首选的意见？就个人而言，我喜欢它在VM / SQL2016级别启用，因为如果您的Nutanix环境中只有一个数据池，则必须为访问该存储的所有系统启用它？

    回复


    Baidu