[HADOOP] hadoop의 모든 액션 전에 ugi.checkTGTAndReloginFromKeytab ()을 호출해야합니까?

hadoop의 모든 액션 전에 ugi.checkTGTAndReloginFromKeytab ()을 호출해야합니까?

내 서버 응용 프로그램에서 Kerberos에 연결하면 내 Java 응용 프로그램에서 Hadoop 클러스터를 보호합니다. HDFS 파일 시스템, Oozie, Hive 등 다양한 구성 요소를 사용하고 있습니다. 응용 프로그램 시작시 전화를 겁니다.

UserGroupInformation.loginUserFromKeytabAndReturnUGI( ... );

이 날 UserGroupInformation 인스턴스를 반환하고 응용 프로그램 수명 동안 유지하십시오. 특권 조치를 취할 때 나는 그들을 ugi.doAs (행동)로 시작합니다.

이것은 잘 작동하지만 UserGroupInformation에서 kerberos 티켓을 갱신해야하는지 궁금합니다. 나는 그것이 만기에 가까울 때마다 티켓 갱신을하는 것으로 보이는 UserGroupInformation.checkTGTAndReloginFromKeytab () 메소드를 발견했다. 또한이 메서드는 WebHdfsFileSystem과 같은 다양한 Hadoop 도구에서 호출되는 것으로 나타났습니다.

이제는 내 서버 응용 프로그램 (수개월 또는 몇 년 동안 실행 중일 수도 있음)이 절대로 티켓 만료를 경험하지 못하도록하려는 경우 가장 좋은 방법은 무엇입니까? 구체적인 질문을 제공하려면 다음을 수행하십시오.

해결법

1. ==============================

   1.하둡 커미터 여기! 이것은 훌륭한 질문입니다.

   하둡 커미터 여기! 이것은 훌륭한 질문입니다.

   유감 스럽지만 응용 프로그램의 특정 사용 패턴에 대한 심층적 인 이해 없이는 이에 대한 명확한 답을 내리기가 어렵습니다. 대신 일반 지침을 제공하고 Hadoop이 자동으로 키 테이블에서 티켓 갱신 또는 다시 로그인을 처리 할 때와 수행하지 않을시기를 설명 할 수 있습니다.

   Hadoop 에코 시스템의 Kerberos 인증의 주요 사용 사례는 인증에 SASL을 사용하는 Hadoop의 RPC 프레임 워크입니다. Hadoop 에코 시스템의 대부분의 데몬 프로세스는 프로세스 시작시 UserGroupInformation # loginUserFromKeytab에 대한 단일 호출을 수행하여이를 처리합니다. 이러한 예로는 NameNode에 대한 RPC 호출을 인증해야하는 HDFS DataNode와 ResourceManager에 대한 호출을 인증해야하는 YARN NodeManager가 있습니다. DataNode와 같은 데몬이 프로세스 시작시 일회성 로그인을 수행 한 다음 전형적인 티켓 만료 시간보다 오래 지난 몇 달 동안 계속 실행 할 수있는 방법은 무엇입니까?

   이것이 일반적인 사용 사례이므로 Hadoop은 RPC 클라이언트 계층 내에 직접 자동 다시 로그인 메커니즘을 구현합니다. 이 코드는 RPC 클라이언트 # handleSaslConnectionFailure 메서드에 표시됩니다.

             // try re-login
             if (UserGroupInformation.isLoginKeytabBased()) {
               UserGroupInformation.getLoginUser().reloginFromKeytab();
             } else if (UserGroupInformation.isLoginTicketBased()) {
               UserGroupInformation.getLoginUser().reloginFromTicketCache();
             }
   

   이것을 재 로그인의 "게으른 평가"라고 생각할 수 있습니다. 시도한 RPC 연결에서 인증 실패에 대한 응답으로 만 로그인을 다시 실행합니다.

   이것을 알면 부분적인 답을 줄 수 있습니다. 응용 프로그램의 사용 패턴이 키탭에서 로그인 한 다음 일반적인 Hadoop RPC 호출을 수행하는 것이라면 자신의 다시 로그인 코드를 굴릴 필요가 없습니다. RPC 클라이언트 계층이 대신 해줍니다. "Typical Hadoop RPC"는 HDFS FileSystem API, YarnClient 및 MapReduce Job 제출물을 포함하여 Hadoop과 상호 작용할 수있는 대다수의 Java API를 의미합니다.

   그러나 일부 애플리케이션 사용 패턴은 Hadoop RPC를 전혀 포함하지 않습니다. 예를 들어 WebHDFS 또는 YARN REST API와 같은 Hadoop의 REST API와 상호 작용하는 애플리케이션이 있습니다. 이 경우 인증 모델은 Hadoop HTTP 인증 문서에 설명 된대로 SPNEGO를 통해 Kerberos를 사용합니다.

   이것을 알면 답에 더 많은 것을 추가 할 수 있습니다. 응용 프로그램의 사용 패턴이 Hadoop RPC를 전혀 사용하지 않고 대신 REST API에만 적용되는 경우 자체 재 로그인 논리를 롤업해야합니다. 이것이 바로 당신이 알아 차린 것처럼 WebHdfsFileSystem이 UserGroupInformation # checkTGTAndReloginFromkeytab을 호출하는 이유입니다. WebHdfsFileSystem은 모든 작업을 수행하기 전에 호출을 선택합니다. UserGroupInformation # checkTGTAndReloginFromkeytab은 만료 될 때만 티켓을 갱신하기 때문에 이는 훌륭한 전략입니다. 그렇지 않은 경우, 호출은 no-op입니다.

   마지막 유스 케이스로, 키탭에서 로그인하지 않고 사용자가 애플리케이션을 시작하기 전에 외부에서 kinit을 실행하도록 요구하는 대화식 프로세스를 고려해 보겠습니다. 대다수의 경우 Hadoop CLI 명령과 같이 단기 실행 응용 프로그램이 될 것입니다. 그러나 경우에 따라서는 이러한 프로세스가 더 오래 실행될 수 있습니다. 장기 실행 프로세스를 지원하기 위해 Hadoop은 배경 스레드를 시작하여 Kerberos 티켓을 만료까지 "닫기"로 갱신합니다. 이 논리는 UserGroupInformation # spawnAutoRenewalThreadForUserCreds에 표시됩니다. RPC 계층에 제공된 자동 다시 로그인 논리와 비교하여 중요한 차이점이 있습니다. 이 경우 Hadoop은 티켓을 갱신하고 수명을 연장 할 수있는 기능 만 있습니다. 티켓은 Kerberos 인프라 스트럭처에 따라 최대 재생 가능 수명을가집니다. 그 후에는 티켓을 더 이상 사용할 수 없습니다. 이 경우 재 로그인은 사용자에게 암호를 다시 묻는 것을 의미하기 때문에 실제로 불가능하며, 터미널에서 멀리 떨어진 곳으로 걸어 갔을 가능성이 큽니다. 즉, 프로세스가 티켓 만료 이후에도 계속 실행되면 더 이상 인증 할 수 없습니다.

   다시 말하지만, 우리는이 정보를 사용하여 전반적인 답을 알릴 수 있습니다. 응용 프로그램을 시작하기 전에 kinit을 통해 대화 형으로 로그인하는 사용자에게 의존하고 응용 프로그램이 Kerberos 티켓의 최대 재생 가능 기간보다 오래 실행되지 않는다고 확신하는 경우 Hadoop 내부를 사용하여 주기적으로 갱신을 처리 할 수 ​​있습니다 .

   keytab 기반 로그인을 사용하고 있고 애플리케이션의 사용 패턴이 Hadoop RPC 레이어의 자동 재 로그인에 의존 할 수 있는지 확실하지 않은 경우 보수적 인 접근 방식을 사용하는 것이 좋습니다. @SamsonScharfrichter가 자신의 롤링에 대한 훌륭한 답을 전했습니다.

   HBase Kerberos 연결 갱신 전략

   마지막으로 API 안정성에 대한 메모를 추가해야합니다. Apache Hadoop 호환성 가이드 라인은 하위 호환성에 대한 세부 사항에 대한 Hadoop 개발 커뮤니티의 약속에 대해 설명합니다. UserGroupInformation의 인터페이스는 LimitedPrivate 및 Evolving으로 주석 처리됩니다. 기술적으로 이것은 UserGroupInformation의 API가 공개로 간주되지 않으며 하위 호환되지 않는 방식으로 진화 할 수 있음을 의미합니다. 실용적인 문제로, 이미 UserGroupInformation의 인터페이스에 의존하는 많은 코드가 있습니다. 따라서 우리는 획기적인 변경을하는 것이 현실적으로 불가능합니다. 확실히 현재 2.x 릴리스 라인 내에서는 메소드 서명이 변경되고 코드를 위반할 것을 두려워하지 않을 것입니다.

   이제이 모든 배경 정보를 얻었으므로 구체적인 질문을 다시 살펴 보겠습니다.

   애플리케이션의 사용 패턴이 Hadoop 클라이언트를 호출하고 Hadoop의 RPC 프레임 워크를 활용하는 것이면이 점에 의지 할 수 있습니다. 애플리케이션의 사용 패턴이 Hadoop REST API 만 호출하는 경우에는이를 신뢰할 수 없습니다.

   애플리케이션의 사용 패턴이 Hadoop RPC 호출 대신 Hadoop REST API를 호출하는 것이라면이 작업이 필요할 수 있습니다. Hadoop의 RPC 클라이언트 내에 구현 된 자동 재 로그인의 이점을 얻지 못할 것입니다.

   인증해야 할 모든 작업 바로 전에 UserGroupInformation # checkTGTAndReloginFromKeytab을 호출하는 것이 좋습니다. 티켓이 만기 가까이에 있지 않으면 메소드는 no-op가됩니다. Kerberos 인프라가 느리고 클라이언트 운영이 재 로그인의 대기 시간 비용을 지불하는 것을 원하지 않는다면 이는 별도의 백그라운드 스레드에서 수행해야 할 이유입니다. 티켓의 실제 만료 시간보다 조금 앞서 가야합니다. 당신은 티켓이 만료까지 "닫혀 있는지"를 결정하기 위해 UserGroupInformation 내부의 로직을 빌릴 수 있습니다. 실제로, 나는 결코 재 로그인의 지연이 문제가된다는 것을 개인적으로 보지 못했습니다.

from https://stackoverflow.com/questions/34616676/should-i-call-ugi-checktgtandreloginfromkeytab-before-every-action-on-hadoop by cc-by-sa and MIT license