Manager全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->Manager->常见故障）Manager经典案例、总结、重大问题见下表：经典案例分类序号案例（点击标签查看详情）出现频次环境类常见故障1-1ssh、su命令执行卡顿导致OMS异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-2网络慢导致Manager页面访问失败：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★1-3/etc/ntp.conf文件权限不对导致ntp异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-4节点健康状态为Bad（故障）：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★★1-5postgresql.conf配置文件有误导致gaussdb异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-6Manager页面上报所有节点ntp服务告警：维护类故障（6.5.X-8.X）>Manager>常见故障>监控告警常见故障★★★　1-7 OS定时任务进程异常导致节点互信异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★OS类常见故障2-1 配置的ntp外部时钟源可以ping通，但是ntp服务不能同步时间：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★★★　2-2系统时间倒退导致NodeAgent无法启动：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★　2-3安装OMS时配置失败：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★★★　2-4suse12.2 pam-systemd导致su、sudo、ssh卡顿问题：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★　节点类常见故障3-1节点上下电导致NodeAgent启动失败：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>节点上下电导致NodeAgent启动失败★★★★3-2Ntp启动失败导致NodeAgent故障：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>Ntp启动失败导致NodeAgent故障★★★3-3修改了/etc/sysconfig/ntpd文件里的内容导致节点故障：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>修改了/etc/sysconfig/ntpd文件里的内容导致节点故障★★★3-4某个节点所有实例均失败， nodeagent不断在重启：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>某个节点所有实例均失败， nodeagent不断在重启★★★

hive全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->hive->常见故障）hive经典案例、总结、重大问题见下表：经典案例分类序号案例出现频次sql优化1.1Hive sql写法问题导致结果异常合集（一）★★1.2Hive sql写法问题导致结果异常合集（二）★★1.3Hive sql写法问题导致运行慢问题合集（一）★★★★1.4Hive sql写法问题导致运行慢问题合集（二）★★★★1.5Hive sql写法问题导致运行慢问题合集（三）★★★★服务异常2.1Hiveserver启动成功，但页面显示状态故障★★2.2Metastore启动故障，报failed to initizlize master key★★2.3Metastore启动故障，报user hive does not belong to hive★★★★

Flink全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131  （FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->Flink->常见故障）经典案例分类序号案例出现频次现网经典案例1.1关于table.exec.state.ttl参数的生效机制★★客户端安装常见问题2.1Flink客户端配置方法(维护宝典：维护类故障（维护类故障（6.5.X-8.X）>Flink>FAQ>下载并配置Flink客户端)★★★★★2.2升级后任务提交失败，报zk节点权限不足(维护宝典：维护类故障（6.5.X-8.X）>Flink>任务提交常见故障>FusionInsight HD大版本从6.5.1升级到8.x版本后任务提交失败)★★★★★2.3开启ssl后，正确的提交方式（维护宝典：维护类故障（6.5.X-8.X）>Flink>任务提交常见故障>创建Flink集群时执行yarn-session.sh命令失败）★★★★★ 

Flink的table.exec.state.ttl参数说明：Flink SQL 新手有可能犯的错误，其中之一就是忘记设置空闲状态保留时间导致状态爆 炸。列举两个场景：➢ FlinkSQL 的 regular join（inner、left、right），左右表的数据都会一直保存在 状态里，不会清理！要么设置 TTL，要么使用 FlinkSQL 的 interval join。➢ 使用 Top-N 语法进行去重，重复数据的出现一般都位于特定区间内（例如一小时 或一天内），过了这段时间之后，对应的状态就不再需要了。Flink SQL 可以指定空闲状态(即未更新的状态)被保留的最小时间，当状态中某个 key 对应的状态未更新的时间达到阈值时，该条状态被自动清理：基于811版本测试，测试SQL的代码如下： EnvironmentSettings.Builder builder = EnvironmentSettings.newInstance();         builder.inStreamingMode();         builder.useBlinkPlanner();         EnvironmentSettings settings = builder.build();         StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); //        env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);          StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env, settings);          env.enableCheckpointing(6000L);       env.setStateBackend(new RocksDBStateBackend("hdfs:///xxxx));//启用hdfs状态后端       env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);       env.getCheckpointConfig().setCheckpointTimeout(600000L);       env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);       env.getCheckpointConfig().setFailOnCheckpointingErrors(false);       env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);          Configuration configuration = tableEnv.getConfig().getConfiguration();         configuration.setString("table.exec.state.ttl","10000");          String sqlTable_1 =                 "CREATE TABLE source1 (\n" +                 "  name varchar(10),\n" +                 "  vaa varchar(10),\n" +                 "  ts AS PROCTIME()\n" +                 ") WITH (\n" +                 "  'connector' = 'kafka',\n" +                 "  'topic' = 'user_source1',\n" +                 "  'properties.bootstrap.servers' = 'kafka:21005',\n" +                 "  'properties.group.id' = 'testGroup',\n" +                 "  'scan.startup.mode' = 'latest-offset',\n" +                 "  'format' = 'csv'\n" +                 ")";          String SqlTable_2 = "" +                 "CREATE TABLE source2 (\n" +                 "  name varchar(10),\n" +                 "  vaa varchar(10),\n" +                 "  ts AS PROCTIME()\n" +                 ") WITH (\n" +                 "  'connector' = 'kafka',\n" +                 "  'topic' = 'user_source2',\n" +                 "  'properties.bootstrap.servers' = 'kafka:21005',\n" +                 "  'properties.group.id' = 'testGroup',\n" +                 "  'scan.startup.mode' = 'latest-offset',\n" +                 "  'format' = 'csv'\n" +                 ")";          String inputTable="create table p (\n" +                 "  name1 varchar(10),\n" +                 "  name2 varchar(10),\n" +                 "  vaa1 varchar(10),\n" +                 "  vaa2 varchar(10)\n" +                 ") with ('connector' = 'print')";          String sql = "insert into\n" +                 "  p\n" +                 "select\n" +                 "  source1.name,\n" +                 "  source2.name,\n" +                 "  source1.vaa,\n" +                 "  source2.vaa\n" +                 "FROM\n" +                 "  source1\n" +                 "  join source2 on source1.name = source2.name";          //创建表1         tableEnv.executeSql(sqlTable_1);         //创建表2         tableEnv.executeSql(SqlTable_2);         //创建输出表         tableEnv.executeSql(inputTable);         //执行结果         tableEnv.executeSql(sql); 执行sql的代码片段如下：在这个用例中我们使用的TTL时间参数为10s失效。当同时输入：topic:user_source1 的数据 zs,aaa   topic:user_source2的数据zs,bbb 结果如下：但是输入：topic:user_source1 的数据ls,aaa 间隔大于10s后输入 topic:user_source2的数据ls,bbb未出现结果：从测试结果来看：（1）常规联接是最通用的联接类型，其中任何新记录或对联接任一侧的更改都是可见的，并且会影响整个联接结果。例如左边有一条新记录，当product id 相等时，它会与右边所有以前和以后的记录合并。SELECT * FROM OrdersINNER JOIN ProductON Orders.productId = Product.id对于流式查询，常规连接的语法是最灵活的，并且允许任何类型的更新（插入、更新、删除）输入表。但是，此操作具有重要的操作含义：它需要将连接输入的两侧永远保持在 Flink 状态。因此，计算查询结果所需的状态可能会无限增长，具体取决于所有输入表和中间连接结果的不同输入行的数量。（2）如果设置了TTL的时间后，过了TTL时间后，之前的状态数据会被删除。

GaussDB 8009集群如果各个节点NTP都配置为第三方服务器ntp会有什么影响？（正常是OMS配置第三方NTP,节点向OMS同步时钟）

【直播主题】华为云FusionInsight 8.2.0 MRS新版本特性能力解读&最佳实践【回看链接】cid:link_1【直播介绍】本期直播将由华为云MRS首席架构师Sailing老师与资深工程师Haoxi老师带大家一起玩转MRS新版本，详细解读全链路实时数据湖、高性能智能化交互式引擎等新方案、新能力。调研问卷：cid:link_0

一、 Kafka request日志打开和关闭方式打开：集群 -> Kafka -> 配置 -> 全部配置 -> kafka.request.log.level配置改为DEBUG后保存。2. 关闭：集群 -> Kafka -> 配置 -> 全部配置 -> kafka.request.log.level配置改为INFO后保存。保存后不用重启Kafka实例，一般建议开5到10分钟。二、 Kafka request分析Kafka request原理 Kafka请求处理模型如下图所示：Kafka server端启动一个Acceptor线程，负责监听socket新的连接请求、注册OP_ACCEPT事件。Acceptor将监听到的新连接以轮询方式发送给ProcessorProcessor注册OP_READ事件，把接收到的请求放到request队列KafkaRequestHandler从Request队列中获取请求交给kafkaApi处理KakfaApi通过其handle()方法执行响应的处理逻辑KakfaApi处理完后将Response放回到Request对应的Processor的ResponseQueue中。processor从response队列中取出待发送的response发送给客户端。Request请求监控指标Request类中request处理流程如下图所示：如上图所示，流程可分为六个阶段：请求被processor放入Request队列等待处理：此过程处理速度与num.io.threads配置有关。IO线程在本地节点处理：处理速度与本节点CPU、IO有关。IO线程在远端节点处理：处理速度与远端节点CPU、IO有关，也与节点间的网络有关。限流等待：与限流设置有关。Response请求放在response队列中等待返回：此过程处理速度与num.network.threads配置有关。Response请求被发送给客户端：处理速度与服务端和客户端的网络有关。以上六个阶段对应的request日志中的指标信息是：requestQueueTime: 请求在request队列中等待时间，此过程耗时多可增大num.io.threads来缓解。localTime: 请求在本节点处理耗时，此过程耗时多可检查节点上的CPU和IO使用率是否高及IO线程数配置是否过小。remoteTime: 请求在其他节点处理耗时，此过程耗时多需检查节点间的网络是否有延迟、对端节点的CPU和IO使用率是否高。throttleTime: 限流的时间。responseQueueTime: 请求在response队列中等待时间此过程耗时多可增大num.network.threads来缓解。sendTime: processor从response队列中获取处理结果并发送给客户端的时间，此过程耗时多说明服务端与客户端网络存在较大延迟。除了上述指标外，request日志中还涉及以下指标：totalTime：请求处理总时间。securityProtocol: 请求的协议类型。principal:User: 请求的用户。clientId：生产和消费如果不设置clientId，Kafka会自动生成clientid，命名为producer-X和consumer-X，副本数据同步的clientId为broker-X-fetcher-X。apiKey：表示所调用的请求。生产和消费问题排查常看的请求有生产请求PRODUCE，消费请求FETCH，元数据请求METADATA，提交offset请求OFFSET_COMMIT。生产请求request日志说明生产请求示例：2020-12-07 11:14:52,861 | DEBUG | [data-plane-kafka-network-thread-1-ListenerName(PLAINTEXT)-PLAINTEXT-5] | Completed request:RequestHeader(apiKey=PRODUCE, apiVersion=5, clientId=producer-1, correlationId=14) -- {acks=1,timeout=30000,numPartitions=1},response:{responses=[{topic=test,partition_responses=[{partition=1,error_code=0,base_offset=4032196,log_append_time=-1,log_start_offset=0}]}],throttle_time_ms=0} from connection 100.112.22.201:21005-10.144.116.89:53748-1;totalTime:0.525,requestQueueTime:0.059,localTime:0.385,remoteTime:0.0,throttleTime:0.074,responseQueueTime:0.036,sendTime:0.056,securityProtocol:PLAINTEXT,principal:User:Default#Principal,listener:PLAINTEXT | kafka.request.logger (RequestChannel.scala:209)生产请求查找关键字：apiKey=PRODUCE、topic=topicName和生产端IP。无论生产端发送数据是否成功，request日志中都有相应的日志信息。Responses信息中的error_code如果为0表示生产段发送数据成功，error_code如果为非0值表示生产端发送数据失败，例如error_code为10，表示生产端发送数据的大小大于服务端设置的消息最大值。三、消费请求request日志说明消费请求示例：2020-12-07 17:41:42,143 | DEBUG | [data-plane-kafka-network-thread-1-ListenerName(PLAINTEXT)-PLAINTEXT-3] | Completed request:RequestHeader(apiKey=FETCH, apiVersion=7, clientId=consumer-1, correlationId=7) -- {replica_id=-1,max_wait_time=500,min_bytes=1,max_bytes=52428800,isolation_level=0,session_id=0,epoch=0,topics=[{topic=test,partitions=[{partition=1,fetch_offset=1500,log_start_offset=-1,max_bytes=1048576},{partition=3,fetch_offset=0,log_start_offset=-1,max_bytes=1048576}]}],forgetten_topics_data=[]},response:{throttle_time_ms=0,error_code=0,session_id=758584167,responses=[{topic=test,partition_responses=[{partition_header={partition=1,error_code=0,high_watermark=5884956,last_stable_offset=-1,log_start_offset=0,aborted_transactions=null},record_set=org.apache.kafka.common.record.FileRecords@40f12818},{partition_header={partition=3,error_code=0,high_watermark=0,last_stable_offset=-1,log_start_offset=0,aborted_transactions=null},record_set=[]}]}]} from connection 100.112.22.201:21005-10.144.116.89:57910-3;totalTime:499.237,requestQueueTime:0.09,localTime:0.549,remoteTime:0.0,throttleTime:0.276,responseQueueTime:0.033,sendTime:498.585,securityProtocol:PLAINTEXT,principal:User:Default#Principal,listener:PLAINTEXT | kafka.request.logger (RequestChannel.scala:209)消费请求查找关键字：apiKey=FETCH、clientId和消费端IP，topic=topicName也可作为查找的依据，但是topics中的内容有时为空，可能查找不到。topics中的内容为空是因为其内容已被缓存在session链路两侧。无论消费是否成功，request日志中都有相应的日志信息。Responses信息中的error_code如果为0表示消费成功，error_code如果为非0值表示消费失败，例如error_code为3，表示服务端没有这个topic partition。

生产性能测试脚本分析使用客户端脚本kafka-producer-perf-test.sh能够测试当前集群的生产的性能基线。如下图：使用方法（以6.5.1版本为例）如下：./kafka-producer-perf-test.sh --topic topicName --num-records 1000000 --record-size 1000 --throughput 20000 --producer.config ../config/producer.properties --print-metrics效果图如下：参数解读：--topic topic名称--num-records 要发送的数据条数--record-size 要发送的单条数据大小--throughput 测试速率显示，建议现网测试的时候如果有生产业务在跑，建议合理设置该值。--producer.config 生产者配置。-print-metrics 打印测试的统计信息。该脚本的测试场景主要用于检测集群的性能基线、检查网络带宽等。注意：在检测性能基线时需要停止业务并且将—throughput 设置为-1。在检测网络带宽时，需要在集群内和集群外的客户端节点分别部署FI的客户端。并对比性能的测试结果。禁止使用该脚本向生产使用的topic中发送数据。消费性能测试脚本分析使用客户端脚本kafka-consumer-perf-test.sh能够测试当前集群的消费的性能基线。使用方法如下：sh kafka-consumer-perf-test.sh --group id1 --topic test --messages 1000 --broker-list kafka业务IP:21007 --consumer.config ../config/consumer.properties –threads 2 --print-metrics--group 为消费用的消费者组，注意一定不要与生产使用的消费者组重复。--topic topic名称--messages 需要消费的消息条数--broker-list broker的业务ip列表–threads 测试使用的消费并行度--print-metrics 是否输出统计信息。该脚本的测试场景主要用于检测集群的性能基线。注意：当使用该脚本测试现网消费性能过程中，groupid需要自己随机指定，禁止使用业务所使用的groupid。在检测网络带宽时，需要在集群内和集群外的客户端节点分别部署FI的客户端。并对比性能的测试结果。注意：如果命令在FusionInsight HD集群内部（例如在主OMS节点部署了kafka客户端）使用以上脚本测试出的性能若不稳定且持续在几M到几十M之间转换并伴随发送超时，则可以认为kafka集群性能异常。如下图如果命令在FusionInsight HD集群外部（非FI集群内部节点）的客户端节点执行性能低于90M但是FI集群内部性能远大于90M，则认为客户端到服务端时间存在带宽问题。

图：client为业务的客户端节点（生产数据、消费数据的节点上图为例，client节点与kafka集群的broker-3节点可能存在网络问题，那么需要用以下的手段进行检测：网络延迟检测：从client节点向broker-3节点发送ping包然后查看前30次的延时，看一下是否有网络抖动，如下命令：ping –s 5000 broker-3IP延时在20ms以内则认为正常。2. 带宽检测：网络延迟没有问题并不代表带宽是正常的，通常带宽的检查方法使用scp命令就能够看出带宽的大小。流程如下：找一个1G左右的压缩文件（不要使用文件夹）执行scp命令，将文件传送到broker-3节点的/tmp目录下，命令如下：scp 文件root@broker-3 ip:/tmp/  执行结果例如如下：如上结果，每秒传送性能在107M左右，如果这个性能低于80M则认为带宽不足或者带宽占用量大。可定性为网络质量问题。

kafka-root.log 位于broker实例所在节点的路径：/var/log/Bigdata/kafka/broker下，该日志里面会统计每分钟kafka磁盘io的使用率，打印信息如下：可以通过Linux命令批量检查一个或者整个集群的io使用情况。         （1）查询一个broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。登录到其中一个broker节点的后台目录/var/log/Bigdata/kafka/broker，执行以下命令cat kafka-root.* |   grep "Collect topic partition" | awk -F'is:' '{print $2}' | awk -F',' '{print $1}' | grep –v "0.0"（2） 查询整个集群所有broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。通过前台将对应时间段的kafka日志全部收集回来在本地全部解压缩后，在根目录下全部查询，zgrep ioUsage ./根目录kafka的目录*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1 " " $2 " " $15}' | grep -v "0.0"例如：如下根目录下kafka的目录名称为n-kafka-* 那么命令为zgrep "ioUsage" ./n-kafka-*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1" "$2 " " $15}' | grep -v "0.0"得出的结果如下：如果以上的结果持续出现0.8~1.0的数值，说明磁盘io在80%~100%之间，磁盘可能存在异常注意：在8.0版本后ioUsage的数据信息被调整为了DEBUG，如果需要该数据需要手动调整broker节点的log4j日志。调整方式如下：1，登录到每个broker节点的/opt/huawei/Bigdata/FusionInsight_Current/*_*_Broker/etc目录下2，打开log4j.properties文件vim log4j.properties3，在最后一行追加log4j.logger.com.huawei.kafka.PartitionStatusMetrics=DEBUG,rootAppender

PR巡检是RAID卡的一个特性，它会周期性的定时巡检磁盘，对数据进行检查校验，以防出错，但是在巡检的时候会导致磁盘读写性能下降。Raid卡缓存写策略，建议使用WB模式，WB：在配置界面中一般体现为“Write Back”等字样。使用此策略后，需要向虚拟磁盘写数据时，会直接写入Cache中，当写入的数据积累到一定程度，RAID卡才将数据刷新到虚拟磁盘，这样不但实现了批量写入，而且提升了数据写入的速度。当控制器Cache收到所有的传输数据后，将给主机返回数据传输完成信号。要使用该策略，要求RAID卡支持数据掉电保护功能，且如果此时超级电容异常，可能导致数据丢失。WT：在配置界面中一般体现为“Write Through”等字样。使用此策略后，RAID卡向虚拟磁盘直接写入数据，不经过Cache。当磁盘子系统接收到所有传输数据后，控制器将给主机返回数据传输完成信号。此策略缺点是写入速度较低。排查方式：针对以上两种场景，均有明显的磁盘IO升高的情况，建议通过3.3章节对kafka-root.log进行检查。如果kafka集群的磁盘部署使用了raid5建议硬件侧关闭PR巡检。开启WB模式

数据压缩是kafka解决空间问题和超大数据问题关键场景，例如：当kafka的磁盘空间不足时，可以使用数据压缩，来节省磁盘空间的使用。当生产端需要向kafka集群发送大量的超大数据（大于1M的数据）时可以通过开启压缩模式来减少传输过程中带来的网络消耗。压缩模式开启有一定的要求，为什么会这样，先看kafka压缩的原理：Kafka服务端使用的topic最终压缩模式（由compression.type决定）为producer。这也就意味着，开启压缩后存在kafka中的数据类型其实本质就是一个压缩包。如下图：     图：客户端与kafka服务端版本一致的存储方式如果客户端与kafka服务端版本不一致会怎样？再看下面的图。                                             图：客户端与kafka服务端版本不一致的存储方式客户端使用的kafka-client-xxxx.jar版本要与服务端的版本不一致时，在kafka的服务端会出现，对数据的“解压缩，再压缩”的过程。这个流程会非常损耗CPU，并且可能会造成kafka的GC超时从而导致kafka集群性能下降。排查方式：如果节点CPU使用率超过80%，或者有kafka的GC时间超过阈值的告警。或者查看异常的broker节点的监控曲线：如果这个节点的GC时间长时间达到了秒级，说明GC不正常。给kafka进程打一个jstack，如果jstack中出现gzip, snappy,lz4,zstd，说明有开启压缩，例如开启了GZIP。解决方案：建议客户升级客户端，保持和服务端一致使用低版本客户端时，禁用压缩

1.SAPHANA对接 2.大数据组件中HDFS、Hive可用通过S3文件系统接口访问S3存储 3.大数据平台支持异构集群部署，在集群中存在不同硬件规格的服务器，允许在CPU类型，内存大小、硬盘数量与容量等方面有差异

FusionInsight HD安全模式下，需要认证，但是有时候需要任务跑在FusionInsight上，写到外部的非认证HBase集群，此时就会出现zk一直无法连接的问题。虽然后面通过去掉zk认证的相关参数，可以对接外部集群，但是对接FusionInsightHD又出现了问题Spark程序大致如下public List read(List list) { Configuration conf; if (isFusion) { JavaSparkContext jsc = new JavaSparkContext(getSparkSession().sparkContext()); conf = HBaseConfiguration.create(jsc.hadoopConfiguration()); try { // 设置zk服务器端认证信息 String krb5Conf = System.getProperty(LoginUtil.JAVA_SECURITY_KRB5_CONF_KEY); String keytab = System.getProperty("spark.yarn.keytab"); String principal = System.getProperty("spark.yarn.principal"); // zk认证和hadoop认证 logger.info("HBaseReader zk principal:{},keytab:{},krb5Conf:{}", new String[]{hadoopPrincipal, keytab, krb5Conf}); LoginUtil.setJaasConf(LoginUtil.ZOOKEEPER_DEFAULT_LOGIN_CONTEXT_NAME, principal, keytab); LoginUtil.setZookeeperServerPrincipal(LoginUtil.ZOOKEEPER_DEFAULT_SERVER_PRINCIPAL); logger.info("HBaseReader hadoop principal:{},keytab:{},krb5Conf:{}", new String[]{principal, keytab, krb5Conf}); LoginUtil.login(principal, keytab, krb5Conf, conf); } catch (Exception e) { logger.error("HBaseReader cannot login", e); throw new RuntimeException("HBaseReader login fail"); } } else { conf = new Configuration(); System.setProperty("zookeeper.sasl.client", "false"); System.clearProperty("java.security.auth.login.config"); System.clearProperty("zookeeper.server.principal"); } conf.set("hbase.zookeeper.quorum", zkServers); conf.set("hbase.zookeeper.property.clientPort", zkPort); conf.set(TableInputFormat.INPUT_TABLE, tableName); conf = addAdditionConfig(conf); JavaPairRDD rdd = new JavaSparkContext(this.getSparkSession().sparkContext()) .newAPIHadoopRDD(conf, TableInputFormat.class, ImmutableBytesWritable.class, Result.class ); JavaRDD rddRow = null; boolean useDefaultConfig = nodeMapping.getMatrix() == null || nodeMapping.getMatrix().length <= 0; if (useDefaultConfig) { rddRow = rdd.mapPartitions(new HBaseResultToRow(rowKeyAlias)); } else { Map> aliasFamilyQualifierMap = new HashMap<>(); for (String[] strings : nodeMapping.getMatrix()) { aliasFamilyQualifierMap.put(strings[2], new Tuple2(strings[0], strings[1])); } rddRow = rdd.mapPartitions(new HBaseResultToRow(aliasFamilyQualifierMap, rowKeyAlias)); } // ..... more }这个就很迷,明明已经 Login success!!!!!!!!!!!!!! 但是HBase访问还是报错2022-10-18 15:55:17,506 | ERROR | [htable-pool2-t1] | SASL authentication failed. The most likely cause is missing or invalid credentials. Consider 'kinit'. | org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:687) javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211) at org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:169) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:620) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$700(RpcClientImpl.java:165) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:750) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:747) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1729) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:747) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:950) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:914) at org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1288) at org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:227) at org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:336) at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.scan(ClientProtos.java:35518) at org.apache.hadoop.hbase.client.ScannerCallable.openScanner(ScannerCallable.java:404) at org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:211) at org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:65) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:218) at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:398) at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:372) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:139) at org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:79) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

什么是OpenStack？OpenStack能做什么？ - 华为 (huawei.com)原文：华为FushionSphere OpenStack简介应该是：FusionSphere OpenStack文中多处有问题。