WEB / WAS 엔지니어로 프로젝트나 외근을 나가다 보면 많이 듣는 단어들이 있다.Failover와 Failback2개의 개념 모두 시스템에 이상이 생긴 경우(정전 작업, 장애 등)를 전재로 한다. Application이 적재되어 있는 WAS와 Client의 요청을 WAS로 분기해 주는 WEB의 입장에선 장애 상황 자체가 상당히 민감한 상황이기 때문에 더욱 신경을 쓰는 부분일 것이다.  1. Failover고가용성 시스템을 운영하기 위해서는 장비 1대만으로는 모든 상황을 극복하기 어렵기 때문에 대부분 여러 대의 장비를 두고 시스템을 운영하게 된다. 예를 들어 장비 A, B가 있다고 가정을 하면 여기서 운영 중인 장비를 Active, 예비 시스템 장비를 Standby라고 정의하게 된다.만약 A 장비에서..

CKA는 CNCF에서 주관하는 Kubernetes 시험이다. CNCF의 Github에서는 각 시험에 대한 curriculum을 제공하고 있다. 시험이 해당 커리큘럼에 따라 출제가 되기 때문에 커리큘럼을 미리 파악하고 있는 것이 중요하다.  GitHub - cncf/curriculum: 📚Open Source Curriculum for CNCF Certification Courses📚Open Source Curriculum for CNCF Certification Courses - cncf/curriculumgithub.com  위의 CNCF CKA 커리큘럼 문서에 따라 정리한 결과는 다음과 같다.  각 카테고리에 대한 세부 사항은 아래와 같다. (2024년 9월 기준) Cluster Architect..

CKA 준비에 앞서 Kubernetes의 기본적인 architecture에 대해 알아보고자 한다.  위의 work flow에서 크게 3가지로 구분을 하면사용자가 kubernetes에 명령을 전달하기 위해 사용하는 Consoleconsole을 통해 들어온 명령을 해석하고 각 node에 전달하는 Master ServerMaster Server에서 송신한 명령을 수신하여 알맞게 처리하는 Worker node각각의 역할에 대해 자세히 알아보고자 한다.1. Consolecommend line을 통해 kubernetes를 사용하고자 하는 사용자가 명령을 전달해 줄 수 있도록 도와주는 장비를 일컫는다.2. Master ServerApi Serverkubernetes에 들어온 명령들을 총괄 컨트롤 하는 Componen..

# 테스트 환경OS : Oracle Linux Server release 8.6JDK : 1.8Tomcat : 9.0.89Nginx ver. : 1.14.1 1. Log 경로 변경NGINX의 기본 로그 경로는 다음과 같다.access_log /var/log/nginx/access.logerror_log /var/log/nginx/error.log log를 따로 빼서 보관하기 위해 아래의 경로를 생성 후access_log /logs/nginx/access_log/access.logerror_log /logs/nginx/error_log/error.log 해당 경로로 nginx.conf에서 설정 값을 변경 후 재 실행하게 되면 Permission denied 에러가 떨어지게 된다. 새로 생서한 Log 경로..

# 테스트 환경OS : Oracle Linux Server release 8.6JDK : 1.8Tomcat : 9.0.89Nginx ver. : 1.14.1 Nginx와 Nginx Plus는 upstream에 속해 있는 서버들을 지속적으로 테스트하고 사용 불가능한 서버에는 요청을 분기시키지 않으며 다시 복구된 서버를 LB 그룹에 추가할 수 있다. 다만 Open Source Nginx의 경우엔 수동적인 health check만 가능하며 활성 상태 및 active 활동 모니터링 대시보드 사용을 위해서는 Nginx Plus를 사용해야 한다. 따라서 현재 환경에선 수동 Health Check만 테스트 진행 1. 테스트 환경 및 설정WAS는 tomcat으로 통일하여 tomcat_1, tomcat_2 두 대를 준비..

WebLogic에서 Application 배포 시 정상적으로 배포가 완료되지 않고 에러가 떨어지며 이슈가 발생하는 이유는 아주 다양하다. 대부분은 instance log에서 배포 시 발생한 error log를 통해 문제점 파악 및 유추가 가능하다. 그러나 당장 방문이 힘들거나 유선 혹은 원격 지원을 통해 해결을 해야 하는 상황이라면 다음 목록을 먼저 확인해 보자. 1. 배치는 완료되었으나 application 시작을 하지 않은 경우WebLogic console을 통하여 배치는 정상적으로 완료를 하였는데 사용자가 서비스는 안된다고 말할 경우 대부분이 application 배치 후 시작을 하지 않은 경우이다. 위와 같이 application이 활성 상태이지만 서비스 페이지 접속이 안된다고 할 경우에는 컨트롤..