华为手机 Chrome 显示“android系统同步功能已停用”

2020-05-11 software android 1 mins 3 图 72 字

手机上的chrome显示了这样的错误，不能同步收藏夹还是挺痛苦的：

可以通过如下步骤打开同步：

设置-用户和账户-右上角竖着的三个点-勾选自动同步。

阿里云2020云原生编程挑战赛

2020-05-09 tech linux troubleshooting 11 mins 6 图 4010 字

一共四道题，在此记录一下。原广告链接：https://tianchi.aliyun.com/specials/promotion/cloudnative

【赛道1】实现一个分布式统计和过滤的链路追踪

用户需要两个程序，一个是数量流（橙色标记）的处理程序，该机器可以获取数据源的http地址，拉取数据后进行处理，并与后端引擎（蓝色标记）通信，最终数据结果在后端引擎机器上落盘。

enter image description here

【赛道2】实现规模化容器静态布局和动态迁移

赛题背景

阿里每年双11不断的创造奇迹的背后，是巨大的资源成本投入，用以支撑峰值流量。每年各种大促、基础设施的升级都有可能会涉及到单元、中心机房站点变化，而这些站点的迁移、变化，我们可能会短时间借助离线资源、云上资源等，也可能会评估采购物理机，无论是采用哪种方式，我们都期望控制成本用尽可能少的资源成本满足当下站点需求。

日常态，我们使用较少的资源满足业务流量需求，但备战各种大促态尤其是双11，容器平台会承担数十万容器扩容诉求，支撑0点峰值流量，满足用户买买买的需求，同时也使得机器资源成本大幅度提升。

在大促规模化场景下，我们希望通过合理容器静态布局及动态迁移能力，在保证业务稳定性前提下，用尽可能少的机器资源来满足大促资源成本的节省，因而集群规模化容器布局成为了我们的关注点。

静态布局

容器平台规模化建站

每年双11大促，阿里容器平台会提前规划多个机房单元流量、容量分布。此阶段各机房单元站点，可能经历从0到1的新建，也可能经历从1到N规模化的容器布局。使得交易流量从日常态倾于大促态。然后经受第一轮全链路建站压测。

动态迁移

集群变化后容器平台按诉求规模化容器迁移。

大促建站后，通过良好的资源运营方式，集群符合90%的大促态，但业务团队会通过全链路压测、特殊的业务大促活动补容/缩容诉求等，使得各个集群资源状态发生变化。
大促结束后，交易流量会从大促态倾于日常态，在此过程中，集群容器会缩容至日常态，同时集团的机器资源会退水并分时复用于其他团队。

赛题准备

根据下面的单元化集群描述，我们会抽取机房单元中容器、宿主机信息并结合站点集群的变化来准备赛题。

多单元机房规模化容器布局
单元机房集群站点变化

enter image description here

初始态: 基础设置环境准备，涉及内核、网络、中间件、存储、集群管理等等验证准备阶段，此时没有任何交易业务容器，涉及到跨bu多团队的协作。
站点火种: 较少的机器、业务容器，用于支撑极少交易流量(如每秒1k笔 / 全局1%%流量)，用于验证交易全链路的正确性，并为未来快速规模化扩容埋下火种。
中间态: 较多的机器、业务容器，用于支撑一定规模交易流量(如每秒万笔流量)，成为一个长期、平稳日常态单元集群，抑或通过建站使得集群规模化补容到濒临大促态。
大促态: 集团大面积封网、全链路压测稳定，迎接大促。
一个不够形象的串联解释: 当我们想要搬家时，购买了很多储物箱(初始态)，但还没到搬家的日期，空闲时先收拾了一部分衣物在部分储物柜中(站点火种)，当真正要搬家之前，此阶段可能还要补充储物柜、清理旧物品等，然后陆陆续续的整理好了一个个的储物柜(中间态)，，直到真正搬家时候(大促态)。

赛题内容

规模化容器静态布局场景。我们准备了确定数量多规格机器资源，使得在满足调度约束条件下，确定数量、多种类的应用容器能在这些机器资源上满足扩容诉求，保证建站的确定性(赛题中我们会给出充足的机器，但真正建站场景我们会先通过计算预估机器)。
规模化容器动态迁移场景。我们会准备一个集群容器静态布局数据，此时集群是一种碎片态。然后通过容器的迁移，按照规则要求尽可能腾空机器资源，过滤空机器，使得碎片态集群现状重新成为饱满态。

赛题挑战

一个单元集群，数万容器、数千主机、核心业务调度约束，综合起来资源碎片问题会更加放大，而这些单元机房可能根本不会有容器的新增，集群会成为我想象中的”饱和态”

静态布局

业界多数调度器均通过不同的策略打分通过queue以one-by-one的方式调度容器，设计上并不感知后续容器信息，串行扩容顺序会左右调度结果，进而极大地可能会导致资源的浪费。下面通过三个容器实例、三台宿主机举例:

enter image description here

动态迁移

enter image description here

赛题数据

应用描述

集团中的应用信息实际以 “应用名

应用分组” 两个维度的形式呈现，同一个应用名下会有多个应用分组，不会出现一个应用分组对应多个应用名。对应关系是一对多的关系(appName:group=1:N)。

集团内部应用与应用、分组与分组之间有各种调度规则约束，如应用分时错峰、CPU/内存密集型应用交错布局，但本赛题简化问题描述，不增加这些复杂约束。
集团应用根据不同画像特性，cpu-model定义了cpu-share、cpu-set 两种类型，内存超卖技术还未规模化铺开，此处我们考量的是保证交易的稳定性的双11大促单元集群中的cpu-set模式、固定内存的核心应用。

【赛道3】服务网格控制面分治体系构建

问题背景

阿里拥有百万级别的服务实例。虽然通过 Nacos 可以解决超大规模服务发现问题，但服务网格的先行者 Istio 却一直是单体全量数据，不能横向扩容。因此我们找个办法，通过让不同的 Pilot 实例负责不同的 Sidecar 即分治方式来支撑超大规模的系统。然而这里的一个挑战是：如何分配 Sidecar 才能让 Pilot 集群整体负载均衡？

为了更好地说明问题，我们先将问题简化成以下模型：

这里说明如下：

三个部分，从上至下分别是：注册中心、Pilot 集群以及应用；
每个应用中 Sidecar 依赖的服务都是一样的，不同应用依赖的服务可能有重叠；
应用可能随时增减、应用的 Sidecar 也可能随时增减；
每个 Pilot 依据连接上来的 Sidecar 实例需要的全部服务，向注册中心发起服务订阅，将结果存于内存中并推送给他们。

由此可见，Pilot 单个实例承压为：Sidecar 连接量 + 服务数据。服务数据越大，意味着推送前处理的数据越多；连接数越多，意味着需要推送的数据越多。因此，这里的性能优化便成了设法降低这两个值，这体现在 Pilot 集群里便是让 Sidecar 连接更均匀，以及减少 Pilot 服务加载的重复度。但这并不简单，因为我们尝试优化一个时，另一个就会变差。例如，如果我们采取随机连接的方式，那么 Sidecar 连接将会比较平均，单个实例的连接数便较小，但每个 Pilot 加载的服务量增加，因为加载的是 Sidecar 依赖的并集；

图1

如果我们采用散列函数按服务依赖映射至 Pilot，单个实例加载的服务会减少，但是多个应用可能会映射到同一 Pilot，连接数又会增加，造成不均匀问题（如图2所示）。

图2

所以，我们需要寻找一个最优解。

问题描述

首先我们简化问题，只在应用维度进行 Sidecar 分配，同时为了更好的地理解问题，我们进行以下抽象：

已知：
- 提供一个应用列表 A，以及每个应用对应的 Sidecar 数量 n；
- 对于每个应用 a，提供一个服务依赖列表 D；
- 已知一个 Pilot 集群，并有 m 个实例。
条件：
- 为了保障 Sidecar 由访问的顺畅，防止惊群，在整个过程中 Pilot 的加载的服务只增不减（即使应用迁移到其它 Pilot 上，加载的数据依然存在），请谨慎调整应用连接的 Pilot；
- 需要支持应用增减，Sidecar 扩容、缩容，变化后每个 Sidecar 需要的服务需要在对应的 Pilot 上找到，不得缺失。
求：
- 每个 Pilot 实例需要挂载的应用列表 P(L)（i ∈ [0, m-1]）。

【复赛预览】实现一个 Serverless 计算服务调度系统

赛题背景

Serverless 计算服务（如函数计算）根据实际代码执行时间和资源规格收费，让使用者无需为闲置资源付费，背后是服务方采用各种手段优化服务端资源利用率。在优化的过程中，一个关键的问题是平衡请求响应时间和资源利用率，即如何在响应延迟可接受范围内使用尽可能少的资源。Serverless计算服务支撑场景的多样性以及不同应用对于响应延迟的不同要求，也给优化带来了一些额外的空间。本题目是关于如何设计和实现一个 Serverless 计算服务的调度系统。

赛题设置

系统分为APIServer，Scheduler和ResourceManager 3个组件，其中APIServer和ResourceManager由平台提供，Scheduler由选手实现。
APIServer提供了Invoke API，该API接受函数名称和event，返回执行结果。
ResourceManager提供了ReserveNode API获得Node和ReleaseNode API释放Node，该Node上有容器管理服务，选手可以调用管理服务在Node上为函数创建和销毁容器。其中函数实现已提供，选手无需关注。
当APIServer接收到Invoke请求后会调用Scheduler的AquireContainer API获得执行函数需要的容器，在该容器上执行函数，执行成功后调用ReturnContainer API归还容器。

指标定义

资源使用时间：获得Node成功后开始计时，同一Node释放成功后结束计时，其差值为资源使用时间。
调度延迟：调用AquireContainer所需时间。

赛题描述

评测程序会以不同QPS调用多个函数，计算调度延迟和资源使用时间，按照一定规则对结果评测。

带内管理带外管理？

2020-05-01 tech linux 3 mins 1080 字

存储设备的管理方式分为带外管理和带内管理两种方式，这两种方式通过不同的通道，均可实现对存储设备的管理。

SNMP、RMON、Web、TELNET这些管理方式属于带内管理。

通过CONSOLE、AUX接口管理和通过某些高端设备具有的100BASE-TX的带外管理端口进行管理的方式属于带外管理。

实现方式

具体实现方法如下：

带外管理：存储设备的管理控制数据与用户业务数据信息在不同的链路传送，即管理一条线，业务一条线。典型的连接方式为：维护终端连接存储设备管理网口或串口，对存储设备进行管理；应用服务器通过业务网口连接存储设备，传输业务数据。这两条链路互相独立。《产品文档》中《配置指南》等手册描述的即为这种方式。
带内管理：存储设备的管理控制数据与用户业务数据信息在相同的链路传送，即管理和业务同一条线。典型的连接方式为：应用服务器通过业务网口连接存储设备，通过在应用服务器侧安装Inband Agent软件（该软件属于HostAgent软件包的一部分），来实现在传输业务数据的同时，也能对存储设备进行管理。

区别

可靠性：带外管理由于业务数据和管理数据分别存在于两条独立链路，故在业务链路出现故障时，仍可通过管理链路登录存储设备进行管理。
管理方式：带外管理可以既可以登录ISM管理软件界面，也可以登录CLI命令行界面，提供了多样化的管理方式。带内管理一般情况下只提供ISM管理方式。
组网：带内管理由于管理和业务在同一链路上，故可以减少连接网线的数量。
功能：带内管理可以协调应用服务器和存储设备共同运作，故在某些情况下可以提升存储设备的性能。

带外管理的作用

减少运营成本、提高运营效率、减少宕机时间、提高服务质量。

带外管理使用场景

网管系统必须通过网络来管理设备。如果无法通过网络访问被管理对象，带内网管系统就失效了，这时候带外网管系统就排上用场了。

运维人员和IT设备不在同一个物理地点。这种类型的网络环境包括所有的电信运营商和银行及有分支机构的政府、企业网络。一旦设备故障无法通过网络解决（telnet 、pcanywhere等手段），运维人员只能到现场解决问题。这种类型的网络通过带外网管可以大幅提高网络运维效率，同时有效降低运维成本。

运维人员与IT设备在同一地点，IT设备数目很多统一管理面临很大难度。这种类型IT环境包括所有IDC、企业的数据中心（非托管）、互联网公司、游戏运营商。运维TEAM需要面对几百台甚至上万台服务器，对设备的访问控制授权、操作记录均需要借助带外网管来完成。

参考资料

FAQ-什么是带外管理和带内管理? - huawei

增强 Kubernetes 网络扩展性和性能 - 阿里

2020-04-26 tech network troubleshooting 5 mins 18 图 1994 字

https://mp.weixin.qq.com/s/e4Ph3scexAZKGHA8Yds3rQ

1. Kubernetes Service 性能和扩展性问题

默认的 Kubernetes 的 Service 实现 kube-proxy，它是使用了 iptables 去配置 Service IP 和负载均衡：

如上图所示：

负载均衡过程的 iptables 链路长，导致网络延时显著增加，就算是 ipvs 模式也是绕不开 iptables 的调用；
扩展性差。iptables 规则同步是全量刷的，Service 和 Pod 数量多了，一次规则同步都得接近 1s；Service 和 Pod 数量多了之后，数据链路性能大幅降低。