금융IT

EOL : End Of Life
- 서비스 혹은 판매에 대한 모든 상태가 종료된 상태
- 더 이상 유지보수 자체가 되지 않음

EUS : End Update Support

EOS : End Of Service
- 서비스 혹은 판매가 중단 된 상태
- 더 이상 서비스 혹은 판매를 할 수 없는 상태
- 다만, H/W의 경우 간혹 부속품에 대해서 교체는 가능하며, S/W의 경우 간혹 업데이트가 일어 날 수 있음

EoSPS : End of Service Pack Support

✅ REDHAT 5, 6, 7 EOL

[RHEL 5]
Release date : 2007년 03월 14일
EOL : 2017년 03월 31일
EOL 연장 : 2020년 11월 30일

[RHEL 6]
Release date : 2010년 10월
EOL : 2020년 11월 30일

[RHEL 7]
Release date : 2014년 06월 10일
EOL : 2024년 06월 30일

REDHAT(RHEL) 7
RHEL 7.1 (ended March 31, 2017)
RHEL 7.2 (ended November 30, 2017)
RHEL 7.3 (ended November 30, 2018)
RHEL 7.4 (ends August 31, 2019)
RHEL 7.5 (ends April 30, 2020)
RHEL 7.6 (ends May 31, 2021)
RHEL 7.7 (ends August 30, 2021; Final RHEL 7 EUS Release)

참고 URL : Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal

✅ CentOS 5, 6, 7 EOL

[CentOS 5]
Release date : 2007년 04월 12일
EOL : 2017년 03월 31일

[CentOS 6]
Release date : 2011년 07월 10일
EOL : 2020년 11월 30일

[CentOS 7]
Release date : 2014년 07월 07일
EOL : 2024년 06월 30일

[CentOS 8]
Release date : 2019년 09월 24일
EOL : 2021년 12월 31일

• CentOS 8은 2021년 12월 31일에 지원 중단
• CentOS는 향후 CentOS Stream 으로 전환
• CentOS Stream는 RHEL 업스트림 (개발) 배포판

✅ AIX 6, 7 EOL

[AIX 6.1]
(AIX 6.1 TL9)
Release Date : 2013년 11월
EoSPS : 2017년 04월 30일 (EOS)

[AIX 7.1]
(AIX 7.1 TL5)
Release Date : 2017년 10월
EoSPS : 2022년 04월 30일 (EOS)

(AIX 7.1 TL4)
Release Date : 2015년 12월
EoSPS : 2019년 12월 31일(추정)

(AIX 7.1 TL3)
Release Date : : 2013년 11월
EoSPS : 2017년 11월 30일

[AIX 7.2]
(AIX 7.2 TL5)
Release Date : : 2020년 11월
EoSPS : 2023년 11월 30일(추정)

(AIX 7.2 TL4)
Release Date : : 2019년 11월
EoSPS : 2022년 11월 30일(추정)

(AIX 7.2 TL3)
Release Date : : 2018년 09월
EoSPS : 2021년 09월 30일

(AIX 7.2 TL2)
Release Date : : 2017년 10월
EoSPS : 2020년 10월 31일

(AIX 7.2 TL1)
Release Date : : 2016년 11월
EoSPS : 2020년 11월 30일

(AIX 7.2 TL0)
Release Date : : 2017년 10월
EoSPS : 2020년 12월 31일

AIX support lifecycle information (ibm.com)

✅ Windows Server 2008, 2012, 2016 EOL

[Windows Server 2008]
시작날짜 : 2008년 05월 06일
일반 종료 날짜 : 2015년 01월 13일
연장된 종료 날짜 : 2020년 01월 14일

[Windows Server 2012 R2]
시작날짜 : 2013년 11월 25일
일반 종료 날짜 : 2018년 10월 09일
연장된 종료 날짜 : 2023년 10월 10일

[Windows Server 2016]
시작날짜 : 2016년 10월 15일
일반 종료 날짜 : 2022년 01월 11일
연장된 종료 날짜 : 2027년 01월 12일

제품 및 서비스 수명 주기 정보 검색 | Microsoft Docs

표기용량과 실제용량 차이는 아래와 같습니다.

해당 차이는 단위가 커질수록 복리의 효과가 나타납니다. 1 KB는 2.3%이지만, 1 MB는 4.6% 차이가 나고, 1 GB는 6.8%, 1 TB가 되면 9.0%가 차이가 나게 됩니다.

'포맷', '파티션' 등 OS, 제조사 등에 따라 추가적인 차이가 발생할 수 있습니다.

보다 정밀한 실제용량이 필요하다면, 제조사에 문의하는 것이 가장 좋을듯합니다.

기억장치/표기 용량과 실제 - 나무위키 (namu.wiki)

** 디스크 증설 작업 후 pv, vg, lv 생성시에 unknown partition table 메시지 발생

-> 해당 디바이스에 파티션 구성이 되어 있지 않아서 create 명령어 수행시마다 뜨는 메시지

(LVM 환경에서 파티션 구성시는 안해도 관계 없음)

방안2) /dev/sdb1을 생성을 통한 조치 방법

✅2TB 이상의 스토리지를 사용할 때는 MBR 방식(msdos) 대신 GPT 방식을 사용해야함

*기본적으로 linux partition은 MBR(Master boot Record) 방식이다. 그런데 이 MBR의 파티션당 최대 크기는 2TB이다.

 따라서 18EB(엑사바이트)까지 파티션 크기를 잡을 수 있는 GPT(GUID partition Table) 방식을 써야한다.

[조치결과]

[조치방안]

** 참고사항

What causes "unknown partition table" events and how can I prevent them from being logged ? - Red Hat Customer Portal

1. OS 버전 확인
    1) base 기준(권장)
# oslevel -qs | more
상단 버전 확인
6100-09-05-1524
6400-09-04-1441 등
    2) 전체 기준
#oslevel -s
6100-09-02-1412

** 6100-09-02-1412는 2014년 12주차에 나온 버전이고, AIX 6.1.9.2버전이자 AIX 6.1 TL9 SP2버전이다.

2. 서버 모델 확인
# uname -M
IBM, 8286-41A
** 시리얼번호 확인도 필요하면 u옵션 사용
# uname -uM

3. CPU 확인
    1) 모델 확인
# prtconf | grep -i processor
Processor Type : PowerPC_POWER8
Processor Clock Speed : 4116 MHz
= 4GHz
    2) Core 확인
HMC 접속하여 해당되는 서버의 특성 선택하여 프로세서 확인 =8Core

4. MEMORY 확인

    command를 통한 확인

# rmss -p
Simulated memory size is 122880 Mb.
= 120GB

    HMC에서 확인(권장)

5. DISK 확인
# lsdev -Cc disk
hdisk0 Available 02-00-00 SAS Disk Drive
hdisk1 Available 02-00-00 SAS Disk Drive
hdisk2 Available 02-00-00 SAS Disk Drive
hdisk3 Available 05-00-00 SAS Disk Drive
hdisk4 Available 05-00-00 SAS Disk Drive
hdisk5 Available 05-00-00 SAS Disk Drive

# lscfg -vl hdisk0
hdisk0 SAS Disk Drive (300000 MB)
= 300GB

✅실제 물리서버의 어느 포트에 케이블이 꽂혀있는지 확인 방법

BMC/iRMC 등에서 어느 어댑터에 케이블이 꽂아져있는지 확인할 수도 있고
아니면 명령어로 물리적 위치를 확인할 수도 있다.(해당되는 인터페이스에 불이 들어옴)
# ethtool -p (인터페이스 명)

✅어느 어댑터에 고정 IP 설정하기 위한 방법(BONDING 구성)

✅만약 ens192와 ens242를 본딩구성하고자 한다면(RHEL 7버전에서)

# cd /etc/sysconfig/network-scripts

# vi ifcfg-ens192
TYPE=Ethernet
BOOTPROTO=none
NAME=ens192
DEVICE=ens192
ONBOOT=yes
MASTER=bond0
SLAVE=yes

# vi ifcfg-ens242
TYPE=Ethernet
BOOTPROTO=none
NAME=ens242
DEVICE=ens242
ONBOOT=yes
MASTER=bond0
SLAVE=yes

# vi ifcfg-bond0
TYPE=Ethernet
BOOTPROTO=none
NAME=bond0
DEVICE=bond0
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"
IPADDR=192.168.0.104
PREFIX=24
GATEWAY=192.168.0.241

# systemctl restart network
# ip a | grep -i up
# cat /proc/net/bonding/bond0

# ping 192.168.0.241

** 만약 본딩 구성을 삭제하고 다시 잡아야한다면
# modprobe -r bonding
# systemctl restart nework

EMC SRDF 구성

** SRDF (Symmetrix Remote Data Facility)
SRDF 소프트웨어 제품군은 미션 크리티컬 환경의 원격 복제에 대한 기준을 제시하는 솔루션입니다. SRDF 솔루션 제품군은 업계 최고의 하이엔드 VMAX 하드웨어 아키텍처를 기반으로 재해 복구 및 무중단 업무 운영 면에서 인정을 받은 솔루션입니다. 또한 탁월한 구축 유연성과 방대한 확장성을 바탕으로 광범위한 원격 복제 기능을 제공합니다. SRDF 제품군은 다음 옵션으로 구성되어 있습니다.

- SRDF/S : 데이터 유출로 인한 손실을 방지하는 동기식 옵션
- SRDF/A : 원거리 복제를 위한 비동기식 옵션
- SRDF/Star : 멀티 사이트 복제 옵션
- SRDF/CG : 스토리지 전체에 걸쳐 연합된 데이터 세트에 대한 정합성 보장 그룹

- Sync(동기 모드) : 일부 증권사에서 사용

: 복제가 실시간으로 보장된다. DWDM 방식(DWDM은 메트로폴리탄 네트워크의 옵션으로 간주)을 이용하여 전송된다.
장점) 시점 및 정합성이 맞다.
단점) 비용이 크고, 구성이 미흡할때 I/O가 밀리면 큰 문제 발생 가능하다.

- Async(비동기 모드) : 보통 카드사에서 많이 사용(15초~25초 정도 차이남)
장점) 데이터의 정합성이 맞다.
단점) 시점이 맞지 않다.

- Adaptive 모드

: 정합성이 맞지 않아서 바람직 하지 않은 방식 (긴급상황 때만 사용)

: 처음에 차이가 많이 날 때 Adaptive 모드로 적용 후 invalid track이 1~2G 남으면 Sync로 변경

Bulk copy -> Adaptive copy

Split 없이 모드만 변경하면 된다.

장점) 호스트 임팩트가 없다.

단점) 데이터의 정합성이 맞지 않다.

** BCV ( Business Continuance Volume)
쉽게 이야기 하면 메인센터에서 DR센터로의 복제 작업이다.
BCV는 근거리용의 내부복제, 디스크 레벨에서의 복제(전통적인 방법), 하드웨어적인 카피를 응용한 박스카피
SRDF는 장거리용의, SanStorage를 사용해서 외부에서 원격지로의 백업이 가능함(하나의 박스카피 내의 복제가 아닌)

** DB I/O가 밀릴 때 sync 문제일 가능성 존재

** CACA, suspended 현상 발생(70% 사용시) -> DWDM망 업체, 스토리지 업체 등 확인 필요
CACA 오류코드 같은 느낌
Suspended는 복제가 끊어지는 증상

** Cache가 75% 차서 SRDF를 끊는것을 CACA라고 함(CACA ISSUE)
-> 100% 차면 호스트가 뻗음

현재 설정된 값 확인

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

performance

설정가능한 값들 리스트 확인

#tuned-adm list

performance

powersave 등등

현재 바라보는 설정값 확인

#tuned-adm active

Current active profile: performance

#systemctl status tuned

Config 파일 확인

#cat /usr/lib/tuned/performance/tuned.conf

cpufreq governor 옵션 일시변경(performance -> powersave)

#cpupower frequency-set -g powersave

cpufreq governor 옵션 영구변경(performance -> powersave)(바라보는 config파일의 설정값을 수정해주면됨)

#vi /usr/lib/tuned/performance/tuned.conf

[cpu]

governor=powersave

vCenter 비정상 서비스일 때 조치 방법

1. root 파티션 차지하고 있는 audit 로그 삭제

✅ 관리 - 설정 - 일반 - 데이터베이스 : 여기에서 로그 정기적 삭제 설정 가능(확인하기)

2. 인벤토리 서비스 계정 리셋(패스워드 초기화)

1) vCenter 스냅샷

2) vCenter ssh 접속

✅ 만약 ssh-keygen 발생시 -> update하기

3) service vmware-vpxd status : stop 확인

4) /usr/lib/vmware-vmdir/bin/vdcadmintool

5) 3번 선택 (force start replication cycle)

6) <vCenter instance IP>@vspher.local

7) &;"'^&\ 등이 포함되지 않는 패스워드가 발급될 때까지 5~6번 반복 수행

8) 발급된 패스워드 기록

9) 암호 업데이트

9-1) /opt/likewise/bin/lwregshell + 엔터

9-2) cd HKEY_THIS_MACHINE\services\vmdir\ + 엔터

9-3) set_value dcAccountPassword "new passwordd" + 엔터

9-4) quit + 엔터

10) vCenter 리부팅

3. ssh 접속 위한 명령어

1) shell set --enabled True

2) shell

4. 서비스 정상 확인

1) service-control --status

5. replication appliance 재구성

✅아래와 같은 에러 메시지가 발생

- provided credentials are not valid

- unable to obtain ssl certificate : bad server response; is a lookupservice listening on the given address

1) 현재 Replication 재구성 : 패스워드 수정 후 save and restart service

2) 인증서 만료 갱신 : generate and install

3) vCenter에서 reprecation id 정보 수집 정상 x -> vCenter 웹화면에서 패스워드 변경 후 재시동

4) 페어링 : vCenter - vSphere Replication - 대상 사이트 - 연결