首先我的pytorch上用到的检测网络是retinaface+peleenet+Bifpn三个网络，在进行转换的时候，走到第三个网络Bifpn时候出现CANNOT FOUND blob 提示，最后爆出了TypeError: None has type NoneType, but expected one of: bytes, unicode，，，如果需要增加工具中不能转换的网络层，请问如何实现呢

 【问卷调查说明】背景介绍：华为智简网络开发者社区长期致力于服务广大数据通信通领域开发者，并努力为大家提供一个“学习、开发、测试、交流”一站式服务平台。为了更好地优化在线开发体验，特组织本次问卷调查，诚挚邀请大家参与反馈。参与方式：在2020.8.18-2020.8.23期间，此贴评论区盖楼回复问卷即可。温馨提示：请先下载附件问卷，回答完毕后直接在评论区上传问卷进行盖楼！奖励规则：1、前20名完成有效问卷者，即可获得保温杯1个。 2、评选5名最佳改进建议者，可额外获得抱枕1个。  【智简网络场景化API示例调查问卷】【答题前须知】◎为单选题，□为多选题，_______需要您输入答案。单选题和多选题以红色标记选项即可。1、您目前从事职业方向：   ◎ 架构师   ◎  开发   ◎  测试   ◎  运维   ◎  项目经理   ◎  网络安全   ◎  产品经理   ◎  其他2、您从事软件开发年限：   ◎  半年内   ◎  半年-1年   ◎  1年-2年   ◎  2年以上3、您日常工作中是否涉及北向API开放接口调用？   ◎  是   ◎  否4、您日常工作中涉及的北向API开放接口调用是应用在什么方面？   □ 运维     □ 行业应用创新     □ 其他__________  5、您接触过哪些软件开发平台：   □  Eclipse   □  IDEA   □  PyCharm   □  华为云DevCloud   □  阿里云开发平台   □  其他__________   □  没有接触过6、您正在使用的软件开发平台是否能够满足您工作中北向API开放接口调用的需求？   ◎  是   ◎  否     如果不满足需求，您的建议是__________7、您是否愿意尝试在线软件开发平台？   ◎  是   ◎  否8、您是否期待场景化API调用和效果及时展示？例如，左侧面板显示室内导航API示例代码，右侧面板显示地图和导航信息，如下图所示：    ◎  是   ◎  否     您对场景化API调用和效果及时展示的建议是__________9、您对当前北向API开放接口调用形式有什么好的建议？     答：__________感谢您的参与，若想了解更多社区详情，请手机端扫描下方二维码或者PC端访问下方链接进入体验https://developer.huaweicloud.com/techfield/network.html    

1、检查AP是R19版本 Check whether the AP version is R19.2、检查如下配置是否丢失：Check whether the following configurations are lost:portal pass dns enable如果没有的话，手工配置到设备上即可。记得保存。If no, manually configure it on the device. Remember to save it.3、如何通过CLI批量下发     How Do I Deliver Batches Through the CLI?等配置下发成功后，删除该CLI   After the configuration is delivered successfully, delete the CLI.4、升级AP版本到V200R019C00SPC805及以后版本。升级完成后，记得进行配置保存。Upgrade the AP version to V200R019C00SPC805 or later. After the upgrade is complete, save the configuration.https://support.huawei.com/enterprise/zh/wlan/airengine-5700-pid-250400208/software/251734814?idAbsPath=fixnode01%7C24030814%7C21782164%7C21782201%7C24017529%7C250400208

                                                                                      边缘计算面临的挑战从边缘计算的定义及架构上可以看出，“边缘”是一个相对云计算中心的概念，这意味着边缘计算的网络覆盖面很广，需要多种资源的协同工作，并且需要与云计算架构实现良好的对接，因而面临着众多挑战。2016年，美国韦恩州立大学的施巍松教授团队提出，边缘计算面临着可编程性、命名、数据抽象、服务管理、隐私及安全和性能指标优化6种挑战，其中，在可编程性、命名、服务管理和隐私及安全问题上，学术界及工业界已经取得了阶段性的成果，本节将对这4种挑战和研究进展进行详细介绍。1 可编程性边缘节点组成的计算平台类似于异构平台，边缘节点的计算与存储能力、运行时间、操作系统和支持 语言等资源都可能是不同的，这意味着开发者需要根据不同种类边缘设备的资源进行程序开发。边缘计算应该是一个动态、灵活的计算平台，能够根据当前的资源分布动态配置计算任务。显然，与硬件资源高度耦合的传统的开发模式并不适用于 边 缘 计算的场 景。为了解决边缘计算的可编程性，需要开发具有高层综合能力的编译工具，使开发者能够使用统一的语言编写程序，由编译平台根据计算任务分配情况自动编译适用于硬件的程序。TVM是一种针对机器学习的跨硬件平台编译器，边缘计算中的机器学习算法主要运行在移动图形处理器（graphicsprocessing unit，GPU）和现场可编程门阵列（field-programmable gate array，FPGA）两类嵌入式处理器中，然而它们使用的编程语言和操作系统架构通常是不同的，且程序部署时需要大量的手动工作。TVM能够实现面向GPU与FPGA的机器学习算法动态移植，已经在几家互联网主流 企业内部开源和使用。2 命名域名系统（domain name system， DNS）等命名机制已经在云计算模型中得到了很好的应用，能够满足当前的大多数网络。但是现有命名机制并不适用于边缘计算，以智能家居中玄关灯随门打开而自动开启为例，边缘计算程序根据玄关灯的唯一ID控制它的开关，如果这个设备被更换，玄关灯的ID将会改变，此时只有更改程序才能实现原有的功能。可见，原有命名机制灵活性较低，因而不能适应边缘计算中动态变化的网络拓扑，同时一些边缘节点的资源不足以支撑原有命名机制的开销。命名数据网络（named data network-ing，NDN）使用内容名字代替地址，例如在玄关灯的场景中，NDN不再需要知道玄关灯的地址，只需要将内容名字统一为“控制玄关灯”，网络就可以自动找到控制玄关灯的节点，进行数据传输。尽管NDN能够适应动态的边缘网络，但它与上层使用地址进行内容分发的网络并不匹配，而且存在安全隐患。清华大学与亚利桑那大学的学者在参考文献中提出了一种使用双栈交换机搭建NDN、局域网混合网络的方法，并对双栈交换机的布局进行了优化，在保持基于IP地址的内容分发的同时，提高了网络的弹性，能够适应边缘计算动态的网络拓扑。3 服务管理服务管理是边缘计算中的关键技术， 2018年IEEE/ACM SEC收录的文章中有20%与这一话题有关。边缘计算中的服务管理应该满足4种特性：差异化，即各类服务应根据其属性分为不同的优先级；可扩展性，即边缘计算中的节点是动态变化的，服务管理应该能够具有灵活的扩展性；隔离性，即应避免服务之间的耦合，当某个应用程序崩溃时，系统应仍能够保持运行；可靠性，即数据传输、设备自身的可靠性对服务非常重要。除此之外，边缘计算场景中的服务管理还面临着云计算与边缘计算目标不一致的独特问题。参考文献提出了一种基于游戏理论的任务分配框架，利用动态反馈激励机制适应边缘计算的动态网络和解决边缘计算与云计算目标冲突的问题。边缘服务器的布局也对边缘计算的服务管理有非常重要的影响，参考文献提出了一种基于资源需求预测的跨区域资源优化模型，首先对计算任务进行拆分和预测，然后根据预测结果使用启发式优化算法求解服务器的布局策略。4 隐私及安全相比于云计算模型，边缘计算模型可以在网络边缘完成一部分数据处理工作，这避免了用户隐私信息在云计算中心或过长的传输链路上被滥用和被窃取的风险，但是边缘计算中多类别、多数量设备的接入也带来了新的隐私及安全问题。首先物联网汇集的数据中很有可能包含用户的隐私，例如在智能家居场景中，宠物监控摄像头包含房屋结构和室内陈设信息。其次，边缘网络的安全性往往是没有保证的，仍然以智能家居为例，有数据显示，有49%的家庭无线网络是不安全的，攻击者可以轻易地破解密码，并窃取信息。即便是部署了安全策略的网络，由于一部分终端设备资源有限而无法部署安全保护方案，仍然会造成网络的不安全。最后，网络边缘的高度动态性也会增加网络的脆弱性。随着用户对隐私与安全的要求越来越严苛，学术界对隐私与安全问题的关注度也越来越高，2017年IEEE/ACM SEC收录安全与隐私主题文章6篇， 2018年则多达13篇，可见边缘计算中隐私与安全方向的研究正处于蓬勃发展期。弗吉尼亚大学学者在参考文献中使用了一种基于二分拓扑威胁模型和交互式对抗深度网络的分类算法实现隐私保护，提出了“隐私分区”的概念，将资源分为可信分区和不可信分区，并进行隔离。更有针对性地，加利福尼亚大学Brian Demsky教授的程序设计语言研究小组提出了一种应用于智能家居场景的隐私保护方法——Vig-ilia，通过限制设备的网络访问增强系统的防御力，Vigilia能在保持很小的资源开销的同时，对网络实现有效的通信限制。

iMaster NCE-Campus第三方对接指导：展示基于iMaster NCE-Campus的北向开放能力以及资源概览，帮助开发者快速了解智简网络开发者社区。iMaster NCE-Campus提供了一组RESTful API，外部的应用程序可以使用HTTPS访问API接口，实现业务下发、网络管理和监控等功能。基础网络API，主要针对网络侧的控制管理运维等，适用于MSP集成代理场景，包含基础服务、网络配置、策略服务、运维监控几大类API。对于租户/MSP，支持租户、站点、设备、账号、地图等基础服务接口。对于交换机或AP设备，支持端口、SSID、VLAN、射频、SNMP/LLDP、DHCP等配置接口。支持接入、安全、认证账号管理等策略服务接口。支持查询链路状态/事件、设备状态/事件，支持重启设备、运维ping/trace探测、恢复出厂等运维接口。https://devzone.huawei.com/cn/enterprise/cloudcampus/quickStart.html#thirdAuth

【问题影响】发生告警的组件数据备份缺失。系统无法还原为当天的数据，系统的可靠性降低。【可能原因】ITA服务器没有正常运行。备份服务器没有正常运行。网络问题。【处理步骤】1、在“FusionAccess > 监控 > 告警”上查看告警是否有ITA服务器异常告警？是，执行步骤 2。否，执行步骤 3。2、解决ITA服务器异常问题。3、使用gandalf帐号登录ITA服务器，查看与备份服务器的网络是否正常。输入ping -c 3 备份服务器的IP，查看通信是否正常？是，执行步骤 5。否，执行步骤 4。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     4、根据现场具体情况定位和排除网络故障。5、在“FusionAccess > 系统 > 系统配置 > 备份配置 > 备份”中，查看已配置的备份服务器类型。类型为Backup Server备份服务器。执行步骤 6。类型为第三方FTP备份服务器，执行步骤 8。6、在“FusionAccess > 监控 > 告警”上查看是否有备份服务器异常告警？是，执行步骤 7。否，执行步骤 9。7、解决备份服务器异常问题。8、请根据第三方FTP备份服务器的相关指导书进行异常排查。确认第三方FTP备份服务器的服务正常后执行步骤 9。9、在“FusionAccess > 系统 > 系统配置 > 备份配置 > 备份”，点击“立即执行备份”。在“系统 > 任务与日志”，查看任务执行进度，等待任务执行完成。10、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【问题影响】AUS服务不可用，无法通过AUS升级用户计算机中的AccessAgent。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。AUS服务器没有正常运行。网络问题。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 2。否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）     2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。否，处理完毕。4、使用gandalf帐号登录ITA服务器，查看与AUS服务器的网络是否正常。输入ping -c 3 AUS服务器的IP，查看通信是否正常。是，执行步骤 7。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     5、根据现场具体情况定位和排除网络故障。6、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 7。否，处理完毕。7、使用管理员帐号登录AUS服务器，调用shell命令service AUSService status。查看AUS服务的状态是否正常。是，执行步骤 9。否，执行步骤 8。8、调用shell命令service AUSService restart重启AUS服务。按照步骤 7再次检测AUS服务是否正常。是，执行步骤 9。否，联系技术支持处理。9、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【问题影响】备份服务不可用，用户无法备份配置的各个组件信息。系统无法还原为当天的数据，系统的可靠性降低。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。备份服务器没有正常运行。网络问题。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 2。否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）     2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。否，处理完毕。4、使用gandalf帐号登录ITA服务器，查看与Backup Server服务器的网络是否正常。输入ping -c 3 Backup Server服务器的IP，查看通信是否正常？是，执行步骤 6。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     5、根据现场具体情况定位和排除网络故障。6、使用管理员帐号登录Backup Server服务器，调用shell命令service vsftpd status，查看ftp服务的状态是否正常？是，执行步骤 9。否，执行步骤 7。7、调用shell命令service vsftpd restart。重启Backup Server服务器的ftp服务。8、按照步骤 6查看ftp服务的状态是否正常？是，执行步骤 9。否，联系技术支持处理。9、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【问题描述】重装主机在第十一步骤初始化服务和实例报错【分析过程】1、报错节点的postinstall日志如下：查看了报错节点和正常节点的cn的postgresql.conf文件发现正常节点enable_prevent_job_task_startup参数是off的而且是被注释的报错节点enable_prevent_job_task_startup参数是on的然后对报错节点进行如下排查：1、对比报错节点和正常节点的二进制包不一致报错节点如下： 正常节点如下：2、发现二进制包不一致后，进一步查询主oms的packaged-distributables下的包发现只有651的包，确定是没有替换软件包导致 替换了软件包的目录下文件如下： 【问题根因】现场环境为6515补丁环境，在打完补丁后未进行替换包的动作未做替换软件包导致【解决方案】按照6515补丁指导书执行了替换包的动作后，重新执行重装主机成功【改进措施】1、确保打补丁的时候安装补丁指导书进行操作，避免遗漏必要的步骤2、在补丁环境做重装主机或者扩容等其他重要操作时，建议通过查询相关目录确认替换软件包步骤是否已经已经执行

【问题影响】UNS服务不可用，TC/SC用户无法登录用户计算机。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。UNS服务器没有正常运行。网络问题。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 2。否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）     2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。否，处理完毕。4、使用gandalf帐号登录ITA服务器，查看与UNS服务器的网络是否正常。输入ping -c 3 UNS服务器的IP，查看通信是否正常。是，执行步骤 7。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     5、根据现场具体情况定位和排除网络故障。6、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 7。否，处理完毕。7、查看UNS服务的状态是否正常。打开CloudClient，地址栏输入https://UNS服务器的业务平面IP地址/services/monitor/monitorStatus，查看UNS服务是否正常。是，执行步骤 11。否，执行步骤 8。浏览器显示结果如果包含下面的数据（有些浏览器会提示下载文件，则下载文件的内容包含如下数据），则UNS服务正常。{"resultCode":0,"WIState":"ok","clientIP":"IP地址"}8、使用管理员帐号登录uns服务器，调用shell命令service WIService restart重启UNS服务。9、按照步骤 7再次检测UNS服务是否正常。是，执行步骤 10。否，联系技术支持处理。10、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 11。否，处理完毕。11、调用shell命令netstat -an | grep 4477查看4477端口是否是监听状态是，执行步骤 12。否，联系技术支持处理。12、ITA服务器的系统防火墙默认是开启的，系统防火墙可能会拦截从UNS返回的消息，请检查ITA服务器的系统防火墙是否关闭。是，联系技术支持处理。否，关闭ITA服务器的系统防火墙。13、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。   

【问题影响】vLB服务不可用，TC/SC用户无法登录用户计算机。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。WI服务异常。vLB服务器没有正常运行。网络问题。产生告警的vLB服务器的HA服务异常。主备vLB服务器的HA服务均异常。【处理步骤】1、在“FusionAccess > 监控 > 告警”上查看是否同时存“HA主备间心跳故障”告警且该告警的附加信息中显示的“对端IP地址”与当前vLB服务器异常的服务器IP地址一致。是，排除产生告警的vLB服务器的HA服务故障。否，执行步骤 3。2、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 3。否，处理完毕。3、在“FusionAccess > 监控 > 告警”上查看是否同时存对端vLB的“ vLB服务器异常”告警。是，排除主备vLB服务器的HA服务故障。否，执行步骤 5。4、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 5。否，处理完毕。5、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 6。否，执行步骤 8。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）   返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准） 6、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 7。7、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 8。否，处理完毕。8、使用gandalf帐号登录ITA服务器，查看与vLB服务器的网络是否正常。输入ping -c 3 vLB服务器的IP，查看通信是否正常。是，执行步骤 11。否，执行步骤 9。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     9、根据现场具体情况定位和排除网络故障。10、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 11。否，处理完毕。11、查看vLB配置的WI服务的状态是否正常。使用管理员帐号登录WI服务器，调用shell命令service WIService status查看WI服务状态是否正常（结果为normal的时候为正常）。是，执行步骤 13。否，执行步骤 12。12、使用管理员帐号登录WI服务器，调用shell命令service WIService restart重启WI服务。13、查看vLB服务的状态是否正常。使用管理员帐号登录vLB服务器，调用shell命令service HAProxy status查看vLB服务状态是否正常（结果为HAProxy is running的时候为正常）。是，执行步骤 15。否，执行步骤 14。14、使用管理员帐号登录vLB服务器，调用shell命令service HAProxy restart重启vLB服务。15、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【问题影响】vAG服务不可用，用户无法通过自助维护平台进行维护，不能在WI界面上查看用户计算机的启动过程。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。vAG服务器没有正常运行。网络问题。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 2。否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）    2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。否，处理完毕。4、使用gandalf帐号登录ITA服务器，查看与vAG服务器的网络是否正常。输入ping -c 3 vAG服务器的业务IP，查看通信是否正常。是，执行步骤 7。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     5、根据现场具体情况定位和排除网络故障。6、等待5分钟后，在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 7。否，处理完毕。7、重启vAG服务。使用gandalf帐号登录vAG服务器。执行命令pkill -9 vncgate结束vncgate进程，vncgate进程会被HA进程拉起。8、执行命令ps -ef | grep vncgate，查看进程是否已正常运行？是，执行步骤 9。否，联系技术支持处理。9、等待5分钟，在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【问题影响】数据库服务器异常会导致严重的后果，如备数据库服务不可用，主备数据库之间数据不同步等，因此数据库服务器应该保持运行中状态，如出现此告警必须当天处理故障。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。数据库服务没有正常运行。网络问题。产生告警的数据库服务器的HA服务异常。【处理步骤】1、在“FusionAccess > 监控 > 告警”上查看是否同时存“HA主备间心跳故障”告警且该告警的附加信息中显示的“对端IP地址”与当前数据库服务器异常的服务器IP地址一致。是，查看HA主备间心跳故障，排除产生告警的数据库服务器的HA服务故障。否，执行步骤 3。2、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 3。否，处理完毕。3、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 4。否，执行步骤 6。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）     4、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 5。5、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 6。否，处理完毕。6、使用gandalf帐号登录ITA服务器，查看与数据库服务器的网络是否正常。输入ping -c 3出现告警的数据库服务器的IP，查看通信是否正常。是，执行步骤 8。否，执行步骤 7。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     7、根据现场具体情况定位和排除网络故障。8、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 9。否，处理完毕。9、使用数据库管理员帐号登录告警IP所指向的数据库服务器，执行shell命令zctl.py -t status -P 按提示输入用户名sys及sys的密码查看数据库服务状态是否为“OPEN”。是，联系技术支持处理。否，执行shell命令zctl.py -t stop && zctl.py -t start重启数据库服务。10、按照步骤 9再次查看数据库服务是否正常。是，执行步骤 11。否，联系技术支持处理。11、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

【】企业IT·开发者必看！为什么云开发是互联网大势所趋？【转载华为云社区】云开发是一个已经存在了很多年的概念，但在过去未能真正成为主流。然而，由于云和软件即服务的宏观趋势的结合，以及技术的进步，如容器技术 Docker 和 Kubernetes，云开发现在有机会最终成为基于云的应用程序的新标准开发。1.什么是云开发？云开发或基于云的开发有许多定义。广泛的定义是云开发是一种软件开发方法，它使用云环境在实际的开发阶段执行未完成的软件。这意味着你的软件在云中运行，它通常不会在你的本地计算机上运行。如果你开发的软件是在云环境中运行的，那么项目的临时环境、测试和生产环境也会在云上。其他一些人将云开发定义为使用基于浏览器和在线的 IDE。虽然基于浏览器的编辑器通常链接到云环境来执行软件，但也可以使用本地编辑器并在云中执行软件。来自 Kubernetes 和 CNCF 社区的另一个更近期的术语是“云原生开发”，但它是一个更普遍的概念，指的是“基于容器的、动态编排的、利用微服务架构的应用程序开发”。因此，它更关注开发什么，而不是如何开发。2.为什么云开发现在有了突破？·商业环境已经发生了变化。包括软件市场的一些变化可能会导致这种开发方式的复兴，甚至是最终的突破。在过去的几年里，软件世界发生了很多变化，使得云开发变得更加顺理成章和简单：使用云来运行软件已经成为常态。如今，使用云来处理生产工作负载已经成为许多公司的标准。这种转变与软件即服务销售模式的出现有关，也是云开发必不可少的第一步——只有当生产负载在云中时，将开发运行时间转移到云中才有意义。因此，云计算的广泛采用也增加了云开发的潜在用户基础。·软件变得越来越复杂随着人工智能（AI）、机器学习（ML）和微服务的兴起，软件的复杂性以及运行这些软件所需的计算资源显著增加。由于本地计算机本身的计算能力有限，它们不能够运行用户想要开发的每一个软件。在某些情况下，这甚至可能使得在开发过程中不可避免地使用云。·软件已经独立于运行环境由于使用了 Docker 和 Kubernetes 等容器技术，软件现在通常被打包在可以在任何环境下运行的容器中，无论是云还是本地环境，只要基础技术是可用的。这意味着，如果你已经在生产负载中使用了 Kubernetes，并且使用了容器，那么从本地开发切换到基于云的开发将非常简单。·一些障碍已被扫除过去的一些挑战现在得到了极大解决，这使得云开发更具可行性：网络传输如果你想在云中开发，你总是需要一个互联网连接来与云进行通信。幸运的是，在过去的几年里，人们的平均网络连接速度越来越快，而且 WiFi 无处不在。由于出于开发目的，通常只更改很小的源代码文件，因此在开发过程中不需要传输太多数据，所以现在的延迟通常是无关紧要的。部署耗时如果你不使用在线 IDE，那么你的代码需要以某种方式转移到云中，并且你的应用程序还需要更新。特别是对于容器技术，新的解决方案例如 DevSpace 可以自动将你的变更传输到云中，并且不需要重新启动容器就可以更新你的应用程序。这样可以减少部署时间ーー因为你不需要为每个小变更重新编译运行所有代码，云开发就像是本地开发。拥抱云的必要性调整遗留应用程序以便它能够在云环境中顺利运行可能 需要相当长的时间。尽管对于是否会有一个（完美的）工具可以将每个软件应用程序转换成完美的本地云应用程序仍然存在疑问，但考虑到云和 SaaS 的宏观趋势，对于越来越多的公司来说，转向云似乎是必要的。控制云访问如果每个开发人员都与云进行交互，他们就需要以某种方式访问云。集中管理和控制这种访问可能是一个巨大的挑战，特别是对于较大的团队。然而，由于公共云解决方案，创建新的基于云的开发实例非常容易。甚至可以只使用一个实例，然后在开发人员之间共享访问权。安全问题在开发过程中，在云中运行代码意味着从一开始，所有的源代码都在云中。这不一定是个问题 ーー 因为大多数公司已经在使用云中的代码库了。云成本如果你使用的是公共云，你必须为你使用的资源付费。如果你的团队中的所有开发人员都需要自己的云环境，那么计算资源的成本可能会很快变得相当高，但是现在这些成本已经能更好的降低，并且更大范围的提高开发者与软件供应商的利润增益。3.云开发的好处？总的来说，条件已经变得更好了，使用云开发比以往任何时候都更容易。现在的问题是企业IT和移动开发者为什么要这么做。无限的计算能力尽管你的计算机只能为本地开发提供有限的资源，但使用云实际上可以提供无穷无尽的计算能力。对于微服务应用程序，开发者可能需要大量的电力来启动和运行所有的服务，有时候这在本地是完全不可能的。在这种情况下，企业如果想继续有效地改进其应用程序，就只能转向云计算ーー这也是为了开发。减少准备工作不管运行环境如何，运行一个应用程序可能需要有很多步骤。但是，如果使用云开发，团队中的一个人可以设置和配置所有东西，所有其他团队成员都可以直接启动。在 Kubernetes 的世界中，这可以通过诸如 Helm DevSpace 等开源工具来实现，在这些工具中，你可以配置整个环境，然后必须将其部署到云环境中。这种可复制性是云的一个主要优势，因为硬件或操作系统之间没有差异。它也非常灵活，你可以根据个人需要进行调整。此外，公共云供应商提供了一系列工具和构建模块，你可以非常快速地开始工作。新的合作可能性和标准化由于标准化，很容易在团队中复制 bug 并相互支持。甚至可以让同事直接访问你的云环境来修复某些内容或分享你的工作成果。这可以带来更多的团队合作，形成一种新的团队合作形式，每个人都可以贡献自己的力量。从任何地方访问由于你的应用程序在开发过程中已经在云中运行，因此你不必总是使用具有非常特定设置的同一台计算机。你可以随意切换本地硬件，这样当你的计算机出现故障需要更换时就更容易了。这也支持现代的工作文化，比如在家工作或者在外工作。生活在 DevOps 文化中在云中直接开发针对云的软件非常有意义，因为在应用程序的整个生命周期中始终使用非常类似的环境。这可以减少将应用程序部署到生产环境后可能出现的错误和问题的数量。为此，基于云的开发将在你的团队中培养 DevOps 文化。开发门槛更低，效率更高提供一个数据接口容易，实现一个功能也容易，难的是解决数据的并发性，负载均衡，数据库吞吐量等难题，而这些恰恰是影响数据响应速度的关键点。而能否以快、以优、以稳制胜恰恰是当今企业发展的关键，也是大家都不可避免要面对和解决的问题。云开发为企业IT和移动开发者提供的一站式后端云服务，可以帮助他们统一构建和管理资源，免去了移动应用开发过程中繁琐的服务器、代码搭建及运维、域名注册及备案、数据接口实现等繁琐流程，让开发者可以专注于业务逻辑的实现，而无需理解后端逻辑及服务器运维知识，开发门槛更低，效率更高。

【问题】ITA服务不可用，管理员无法管理计算机或应用服务器。【可能存在的原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除，请重新配置告警组件信息。网络问题。ITA服务器没有正常运行。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。   是，执行步骤 2。   否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0  Sent 3 probes (3 broadcast(s))  Received 0 response(s)  （注：以上IP仅为举例，应以实际IP为准）返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0  Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms  Sent 1 probes (1 broadcast(s))  Received 1 response(s)  （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。 否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。 否，处理完毕。4、使用gandalf帐号登录未故障的ITA。输入ping -c 3 ITA服务器的IP，查看通信是否正常。是，执行步骤 7。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data.  64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms  64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms  64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms  （注：以上IP仅为举例，应以实际IP为准）5、根据现场具体情况定位和排除网络故障。 6、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 7。否，处理完毕。7、在浏览器中，输入“FusionAccess”网络地址，按“Enter”。地址格式为http://ITA服务器的业务平面IP地址:8081。例如，在浏览器中输入“http://192.168.131.62:8081”。进入“FusionAccess”登录界面。8、输入“用户名”、“密码”。9、单击“登录”。10、是否能够正常登录“FusionAccess”？是，执行步骤 12。否，执行11。11、重启ITA服务器。12、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 13。否，处理完毕。 13、使用工具恢复故障服务器，具体操作请参见恢复ITA/GaussDB/HDC/WI/License/vAG/vLB/LiteAS服务器。14、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。