郴州新网app下载,seo代做,网易企业邮箱入口登录,深圳深圳网站开发关于Kubernetes中的数据库#xff0c;大家最关心的第一个问题是性能。由于这种担心的存在#xff0c;许多使用Kubernetes进行生产应用程序工作的客户正在Kubernetes之外的裸机或VM上运行数据库。因此#xff0c;我们致力于深入研究Kubernetes抽象层#xff0c;确定值得测试… 关于Kubernetes中的数据库大家最关心的第一个问题是性能。由于这种担心的存在许多使用Kubernetes进行生产应用程序工作的客户正在Kubernetes之外的裸机或VM上运行数据库。因此我们致力于深入研究Kubernetes抽象层确定值得测试的关键领域并设计有用的基准。我们从网络入手因为由于需要在大多数Kubernetes环境中利用网络存储来提高弹性因此网络对性能的影响很大。此外我们知道联网一直是容器化领域不断挑战和改进的领域。最后对于考虑将其数据库工作负载迁移到Kubernetes的人们来说我们通常将性能视为网络采用的主要障碍而将网络性能视为特定的主要障碍。拥有一个数据库到Kubernetes的桥梁是很有价值的这使在这里运行生产工作负载更加可行。最后我们想了解在Kubernetes中运行数据库所需的一切。这篇博客文章直接基于这些努力的结果。基准方法为了进行此基准测试我们试图建立一种方法来专门隔离尽可能多的变量以专门研究网络如何影响性能。为此我们确保使用的数据集适合内存在执行运行之前预热所有缓存在Kubernetes中利用本地存储并执行足够的基准测试运行以消除可变性。我们还希望数据能够进行真正的比较因此我们确保通过基础架构拓扑进行比较。我们的测试数据中心内机柜中的五台物理服务器中的每台都连接到机架式10GbE和机架式1GbE交换机该交换机包括位于单独IP子网中的两个单独的物理网络。五台服务器中的一台充当sysbench客户端用于模拟工作负载其余四台由Kubernetes和Database角色组成。在裸机测试期间这三台服务器作为Kubernetes节点按原样运行在Kubernetes测试期间这三台服务器被部署为托管数据库Pod的节点而第四台服务器被预留为仅充当Kubernetes Master。为了部署Kubernetes环境我们使用了kubeadm并尝试尽可能保持基本默认设置以确保我们在测试中不会产生混杂因素。我们使用了Kubernetes 1.16。在Percona XtraDB群集5.7.27-31.39的基础上使用Percona XtraDB群集的Percona Kubernetes Operator 1.2.0版本部署了Percona XtraDB群集。为了部署裸机环境使用来自我们公共仓库的Percona XtraDB Cluster 5.7.27-31.39的Percona装运包手动执行安装。在这两种情况下我们都禁用ProxySQL并将Percona XtraDB Cluster群集成员直接暴露给网络并配置了sysbench客户端以便所有流量仅定向到Percona XtraDB Cluster群集的单个成员。对于裸机测试和基于Kubernetes的测试主机操作系统都是Ubuntu 16.04 LTS该内核运行的内核版本为4.15.0-66与Ubuntu 16.04 LTS一起提供。服务器中包含的硬件如下对于环境设置我们按照提供的说明将每个CNI插件安装在Kubernetes的全新部署中以确保它通过10GbE网络发送流量。我们使用sysbench和oltp读写工作负载运行数据库基准测试。此外我们使用iPerf3捕获了网络吞吐量数据。为了确保数据库本身不是瓶颈我们利用了经过优化的MySQL配置该配置作为ConfigMap提供给Kubernetes Operator。最后对于本地存储我们利用Kubernetes中的HostPath方法来确保我们可以为数据库提供卷而不会越过网络边界从而只有事务和复制工作负载会接触到网络。我们调整的my.cnf如下[mysqld]
table_open_cache 200000
table_open_cache_instances64
back_log3500
max_connections4000
innodb_file_per_table
innodb_log_file_size10G
innodb_log_files_in_group2
innodb_open_files4000
innodb_buffer_pool_size100G
innodb_buffer_pool_instances8
innodb_log_buffer_size64M
innodb_flush_log_at_trx_commit 1
innodb_doublewrite1
innodb_flush_method O_DIRECT
innodb_file_per_table 1
innodb_autoinc_lock_mode2
innodb_io_capacity2000
innodb_io_capacity_max4000
wsrep_slave_threads16
wsrep_provider_optionsgcs.fc_limit16;evs.send_window4;evs.user_send_window2
我们对Kubernetes中资源的调整设置如下resources:
requests:
memory: 150G
cpu: 55
limits:
memory: 150G
cpu: 55
我们这样做是因为Kubernetes中的Pod资源服务质量QoS。Kubernetes根据Pod的请求和限制设置为Pod提供不同级别的QoS。在典型情况下您仅指定请求块而不指定限制Kubernetes使用“尽力而为QoS”但是当为所有容器中的所有资源设置请求和限制并且它们相等时Kubernetes将改为使用“保证的QoS”。这可能会对性能差异产生重大影响。此外您需要了解以下用于运行测试的sysbench命令行./sysbench --testtests/db/oltp.lua --oltp_tables_count10 -- oltp_table_size10000000 --num-threads64 --mysql-host172.16.0.4 -- mysql-port30444 --mysql-userroot --mysql-passwordroot_password --mysql-dbsbtest10t --oltp-read-onlyoff --max-time1800 --max- requests0 --report-interval1 --rand-typepareto --rand-initon run
我们测试了哪些CNI插件我们选择了CNI插件来进行测试基于我们与客户和合作伙伴以及一些由于性能原因而特别有趣的参与者的经验。该列表没有特别的顺序我们的目标不是总结使用哪个插件的具体建议。所有CNI插件的项目目标都不同这导致它们进行不同的设计和工程折衷这可能会对性能产生影响但是根据您的环境这些折衷可能是合理的。Project Calico由于其简单性您可以将可路由IP分配给Pods并将其与您现有的机架式网络设备集成在一起因此Project Calico是许多进行内部部署的企业的热门选择。因此我们测试了启用默认和禁用IP-in-IP的Calico。FlannelFlannel是带有Kubernetes的网络结构支持可插入后端。默认后端基于UDP但它也支持vxlan和host-gw后端。我们无法使host-gw正常工作但是我们能够使用UDP和vxlan进行测试。CiliumCilium是使用BPF和XDP的API感知网络和安全性。主要侧重于网络安全政策用例。它的安装非常简单但是在可用的基准测试时间内我们无法使其跨10GbE网络进行路由这显然影响了性能结果。否则测试成功了但请记住我们仍在报告这些结果。Weave (weave-net)Weave是一个紧密集成且易于部署的多主机容器联网系统。尽管显示Pods已在我们的10GbE网络块中分配了IP但流量仍在1GbE网络中路由。我们花费了大量时间来解决此问题但在可用时间内无法解决。我们仍在报告这些结果。Intel SR-IOV and MultusMultus是一个CNI插件可将多个网络接口附加到Pod。这是必需的因为SR-IOV CNI插件不能是您唯一的Pod网络它是默认Pod网络之外的附加接口。我们将Kube-Router用于默认的Pod网络并为此测试分配了另一个10GbE网络上的SR-IOV接口。SR-IOV具有复杂的设置过程但允许将大部分网络卸载到硬件并有效地将硬件VF中的虚拟NIC分配给作为网络设备的主机上的每个Pod。从理论上讲它应该具有接近线速的性能因此值得尝试的复杂性。Kube-RouterKube-Router是Kubernetes网络的简单交钥匙解决方案。它也是kubeadm部署的默认插件因此部署非常简单。最小的功能集所产生的开销很少您将在结果中看到这一点。结论作为基准我们首先在裸机上进行了测试并表明我们的基准仅受网络性能的限制。在这些测试中我们在1GbE上达到了2700 tps在10GbE上达到了7302 tps。一个非常有趣的结果是由iPerf3衡量的网络吞吐量与由sysbench衡量的数据库吞吐量之间的相关性强。SR-IOV打破了这种相关性我们期望它是性能最好的。它具有接近裸机的网络吞吐量但是大约是预期数据库吞吐量的一半。我们怀疑此结果与事务大小有关这是由于SR-IOV固有的硬件虚拟化层内部发生延迟导致的因此我们计划在将来的基准测试中验证这种怀疑。我们发现的另一个关键问题是即使在使用Kube-Router的最佳情况下与在Kubernetes中运行裸机相比我们也看到数据库性能下降了约13。这说明在Kubernetes中仍需要对容器网络的性能进行改进。以下为3月19日开源要闻推荐Spectro Cloud获得750万美元融资提升托管Kubernetes体验Kubernetes是一个非常流行的容器管理平台但是如果要使用它则几乎必须在让别人为您管理它还是自己构建它之间进行选择。Spectro Cloud脱颖而出获得了750万美元的投资并正致力于为您提供介于中间的第三种选择。资金由Sierra Ventures领导Boldstart Ventures参与。Boldstart创始人Ed Sim说他喜欢Spectro Cloud的团队和技术。Spectro Cloud解决了每个大型企业都在努力解决的巨大难题如何在托管平台上推出自己的Kubernetes服务而又不依赖任何大型供应商。Spectro联合创始人兼首席执行官Tenry Fu表示企业不应该在控制和易用性之间妥协。“我们希望成为第一家为企业带来易于使用的托管Kubernetes体验的公司同时也使他们能够灵活地大规模定义自己的Kubernetes基础架构堆栈” Fu解释说。Fu说在这种情况下堆栈由Kubernetes版本的基础操作系统存储网络和其他层如安全性日志记录监视负载平衡或与Kubernetes相关的任何基础结构组成。他解释说“在企业内的组织内您可以满足各个组的需求就基础结构堆栈中的内容而言可以降至相当细致的水平因此您不必担心生命周期管理。”这是因为Spectro Cloud会为您处理这些问题同时仍为您提供控制权。这为企业开发人员提供了更大的部署灵活性并且使他们能够更轻松地在云基础架构提供商之间迁移这是当今公司的头等大事因为公司不想将自己锁定在一个供应商中。“存在一个基础设施控制连续体迫使企业必须权衡这些需求。在一个极端情况下托管产品围绕易用性提供了一种必杀技但这是以控制您所处的云之类的东西或采用新的生态系统选项例如Kubernetes的更新版本为代价的。虽然还处于发展初期但该公司一直在与16个Beta客户合作。GNOME 3.36可提供基于Fedora 32 Beta Linux的操作系统Fedora是Linux发行版之一。它不浮华相反要稳定可靠。这就是为什么许多Linux用户在尝试其他发行版后又回到Fedora的原因。GNOME的爱好者尤其喜欢Fedora因为该操作系统是体验桌面环境的最佳方法之一。近日Fedora 32 Beta可以进行测试了。它随GNOME 3.36一起提供最新、最好的桌面环境版本。如果您不是GNOME的粉丝您可以选择KDE PlasmaCinnamonMATE等。甚至还有Fedora 32的特殊ARM变体可与Raspberry Pi设备一起使用。“ Fedora 32 Workstation Beta中的新增功能默认情况下启用EarlyOOM。EarlyOOM使用户可以在低内存情况下通过频繁交换使用来更快地恢复并重新获得对系统的控制。Fedora32 Workstation Beta默认还启用fs.trim计时器可以改善固态硬盘的性能和磨损平衡。” Fedora项目的Matthew Miller说。Miller进一步说“ Fedora 32 Beta包含许多流行的软件包的更新版本例如RubyPython和Perl。它还包含流行的GNU编译器集合GCC的版本10。我们还对底层基础结构软件进行了常规更新例如GNU C库。”但是在安装Fedora 32 Beta之前请记住这是一个预发行的操作系统。它很可能包含错误可能会导致潜在的数据丢失。建议在安装之前先通读并了解已知错误信息。微软发布VS Code Docker扩充套件1.0微软推出Visual Studio Code的第一个Docker扩充套件主要版本这个新版本更好地支持Python网页框架并且为Python和.NET Core开发人员提供与Node.js相同的Compose支持开发者使用Docker扩充套件建构、执行和除错容器化应用程序将会更简单。回应开发人员的建议微软提升Docker扩充套件对Python网页框架Django与Flask的支持程度由于当工作区添加Docker档案时开发者可以选择要使用Django或是Flask而现在系统会自动架构出Dockerfile、除错任务以及启动配置。微软提到Docker扩充套件仍会继续支持一般选项供开发者取得更通用的Dockerfile。Docker扩充套件现在支持使用Compose.yml档案或是Dockerfile。微软表示当用户只需要启动带有少量参数的单一容器可以仅使用Dockerfile但是要一次启动一个以上的服务或是要启动一个服务但是要修改多个Docker执行参数就可以使用Docker Compose。除此之外Docker扩充套件针对Node.js、Python和.NET Core开发语言支持使用Dockerfile对单一服务进行整合性除错。在这个新版本中用户可以自定义各种命令像是执行映像档时指定扩充套件将产生的容器放置在特定的网络上等。最多使用者要求的更新是希望在执行像是启动、停止或是删除映像档等命令时可以一次选择多个容器或是映像档因此微软这次新增了功能让用户可以一次选择多个容器或映像档并从右键选单选择要对选定项目执行的命令。另外当用户执行包含WSL 2Windows Subsystem for Linux 2的Windows版本可以在Docker Desktop中启动WSL 2实验引擎该引擎会以WSL 2执行而非使用HyperV执行Linux容器微软表示他们从Docker扩充套件0.9版本开始就支持并且鼓励使用WSL 2。IBM今年力推6大云原生软件产品组合Cloud PaksIBM完成红帽并购案后去年秋季发布并以非正式方式向媒体介绍了全新云原生软件产品组合Cloud Paks以容器化技术将软件整合为多组解决方案。近日IBM在线上举办的记者会正式介绍了这个以套餐形式设计的云端软件产品组合。IBM今年重要策略宗旨是以认知型企业Cognitive Enterprise混合多云平台为核心提供IBM Cloud Paks、Red Hat、IBM Cloud的解决方案。在IBM完成红帽并购案后IBM将既有的软件平台与红帽产品线进行整合推出6个Cloud Paks涵盖了企业客户端到端的整个数字化转型过程所需要的产品线与服务。他更提到在数字化转型过程中企业面临混合多重云是必然的趋势。IBM Cloud Paks包括的6大产品线分为应用程序开发解决方案Cloud Pak for Applications、自动化资料分析解决方案Cloud Pak for Data、整合套件组Cloud Pak for Integration、流程自动组Cloud Pak for Automation、混合云管理解决方案Cloud Pak for Multicloud Management这前5项都在去年秋季已在国外发布新增的第6个信息安全解决方案Cloud Pak for Security是IBM去年第四季的最新发布。Gartner企业短期抗疫推BCP得留意细节新冠状病毒全球大流行的现状直接冲击了企业的营运表现不少企业早已订定了一套营运持续计划BCP或因应疫情紧急订定不过Gartner 在最近一场研讨会中提醒企业订定BCP得留意许多细节例如不同因应情境的时间单位不一样。Gartner建议BCP应加入时间的概念即时反应以小时为单位、復原措施则可以天数衡量、另外还要有以周或月为单位的长期应对策略并在事件发生后的不同时间内执行对应的措施企业应该认知到整体反应时间不断缩短。比如过去核心系统中断还能容忍以天为单位的修復时间但现在就算赶在几个小时内修復也可能不被业务单位所接受。另外订定BCP的同时也要一并考量到触发应变措施的条件以及负责执行者来减少应变过程中的不确定性以及因不确定性而导致的决策缓慢才不会错过最佳执行计划的时机。同时设定明确的触发条件也更易于与员工沟通。Gartner举例比如设定1位员工病毒检测阳性就触发对应的计划。营运持续计划BCP是企业风险管理的一环但令人沮丧的事实是许多企业并无意识到风险管理的重要性。Gartner观察部分企业的风险管理业务没有指定负责人、负责人经验也不足也并非因自身业务需求去评估风险反而是受到外部法规所驱动甚至没有订定系统性的营运持续计划再者绝大多数利益相关者缺乏相关意识就算有计划也未展开压力测试和相关演习。对于企业被动、缺乏组织性的风险管理现况Gartner建议企业应根据自身所属行业、地理位置等面向进行风险评估订定出适合自己的营运持续计划比如根据B2B或B2C的业务类型、容易发生地震或颱风的地理位置属性不同对业务的影响也不同需要确实评估与分析接着应先拟定大方向的復原策略、再进一步订定细节若预设的情境真实发生就须确实执行计划若没发生也应定期安排演习并持续透过测试来改进流程。面对新冠状病毒疫情许多企业要在短期内维运远距工作的IT环境比如确保员工能连线到公司并维持工作效率、确保远距办公的资讯安全或实践IT维运的A、B分组机制等。不过Gartner也表示CIO除了基本的IT支持应向更多长期的IT维运面向来进行探索。比如说企业面对疫情可能会走向数字化化业务与数字化生态系或是改为采用RPA等自动化技术甚至因疫情长期对供应链的冲击可能因供应链转移、流动到其他地区引发企业并购等重新配置的状况。面对企业在疫情中可能发展出的新商业模式、工作流程、或客户的新需求IT系统是否有足够的弹性来因应这是CIO可以趁这一波疫情思考的问题。Gartner表示。Gartner的一篇报告中也举例部分企业制造业已经根据疫情需求来调整产品类型。比如日本电子产品制造商夏普Sharp将其中一家工厂改为制作口罩而中国富士康也将其部分因疫情而需求低迷的传统产品改为生产需求更高的产品如防护装备等。这都是快速因应新商业模式而做出改变的案例。因此Gartner也建议企业可以藉着疫情来加速数字化转型比如导入敏捷开发流程来改变企业内部文化与工作方式之前一直没机会做的现在是一个好机会将一些新的工作方式、新的思维方式进行实践来提升整个团队、企业的能力帮助企业在危机中胜出。在IT预算上多数CIO为了因应疫情对企业造成的冲击已经规划缩减IT预算来降低企业整体营运成本。不过Gartner指出企业IT成本通常占整体企业的210%就算消减IT预算对企业的效果有限因此CIO也可以思考如何进行成本优化、甚至价值优化来更有效的提升业务流程的效率与价值。首先在IT成本降低方面CIO可能采取的作法包括停办一些培训、供应商活动或降低顾问的支出也可能对员工进行交叉培训让每位员工获得更多技能来减少员工数的增长其他作法还包括推迟大型IT项目的建置或是减少员工奖金的发放来直接降低IT预算。不过CIO也能进一步思考如何透过IT来提升业务流程的效率与生产力帮企业降低整体业务的预算支出。比如投资远距工作、协作工具、安全工具或是评估业务上云的可能来实际增加业务效率并降低业务本身执行的成本。甚至CIO还能藉此理清业务对IT的需求。最后一步则是直接透过IT来赋予业务新价值达到价值的优化。对此Gartner也提醒CIO要制定预算缩减计划时也要根据可能发生的场景来订定多种方案比如以预算缩减比例为指标在需要缩减不同比例的预算时采取对应的措施随着情况不同而调整。CIO面对新冠状病毒疫情冲击可能需要缩减IT预算但除了预算的直接缩减用IT来提升业务效率与生产力进而减少业务的预算支出也是一种解方。微软Windows 10安装数终于达到10亿微软在2015年正式推出Windows 10操作系统它除了成为所有微软装置的操作系统之外也透过定期的更新来取代名称的世代更迭当时微软发下豪语要在2017年中让Windows 10的全球安装数量达到10亿不过微软一直到本周才抵达此一目标迟到了近3年。现在的Windows 10不只被安装在个人电脑上它也是Xbox游戏机、Surface装置、及HoloLens所使用的平台根据微软的统计有超过1000家的制造商生产了超过8万款不同配置的Windows 10笔电与二合一装置。此外在财富杂誌《Fortune》的全球五百大企业中全部都使用了Windows 10装置。在Windows 10问世之后微软放弃了每三年进行大改版并更名的Windows开发策略而是一年进行数次的功能与安全更新。而微软在今年发表的、基于Chromium的Edge浏览器未来将能独立更新也能支持更多版本的Windows。在达到10亿的安装门槛之后微软承诺未来将继续投资各种版本的Windows 10不管是供PC使用的或者是Windows IoT、Windows 10 Teams edition for Surface Hub、Windows Server、Windows Mixed Reality on HoloLens、Windows 10 in S mode或Windows 10X以满足不同客户的需求。七家科技大厂发表共同抵抗新冠状病毒的联合声明Google、脸书、微软、Linkedin、reddit、Twitter与YouTube等网络平台在本周发表了联合声明承诺它们将与全球的政府医疗机构合作递送与新冠状病毒COVID-19相关的正确资讯并扫盪不实资讯共同捍卫全球社群的健康与安全。声明的内容简单扼要表示将在有关新冠状病毒COVID-19的应对上彼此合作包括协助数百万的人们彼此联繫也会共同对抗COVID-19病毒的诈骗与不实资讯在各自的平台上突显官方的内容也会与全球政府的医疗机构合作发布重大的资讯更新亦邀请其它的企业参与以共同捍卫人们的健康与安全。其实早在发表此一声明之前各大科技业者都已针对新冠状病毒疫情采取了行动例如脸书与Twitter都已禁止了可能造成伤害的不实内容Google也宣布要移除搜寻结果与YouTube的不实内容Google更于本周宣布要设立一个有关疫情的资讯网站而微软则推出了新冠状病毒疫情追踪地图网站。业者的共同声明替各内容平台带来了一个因应疫情的准则避免不实资讯的传递或造成民众的恐慌。
