esxi에서 mount 중인 nfs 볼륨의 타겟 스토리지의 문제로 미쳐 볼륨을 umount를 하지 못한 경우, datastore에서 해당 볼륨을 삭제하려고 하면 에러와 함께 삭제가 되지 않는다. 그럴 때는 아래와 같은 방법으로 삭제하면 된다. 1. esxi에 ssh로 접속후 볼륨 리스트 확인 [root@localhost:~]
vmware esxi 유용한 command
process top [root@localhost:~] esxtop 6:03:30am up 72 days 22:05, 593 worlds, 11 VMs, 24 vCPUs; CPU load average: 0.12, 0.12, 0.15 PCPU USED(%): 10 12 93 13 AVG: 32 PCPU UTIL(%): 10 11 94 14 AVG: 32 ID GID NAME
script for file create
이슈 상황 DB의 특정 테이블을 백업하는 스크립트를 cron을 통해 수행하는데 종종 백업파일이 생성되지 않는 이슈가 발생 원인 원인은 모르지만 우선 백업을 받아야 하기때문에 유사한 재현 스크립트를 통해 테스트 후 해결책을 적용 스크립트 내용 [root@pyhost ~]# cat ctest.sh #/bin/bash
Applying https on the WordPress Web
이 문서에서는 아래 두 가지 내용을 다룬다. Let’s Encrypt 을 통해 무료로 웹사이트에 SSL 적용 Really Simple SSL 플러그인으로 SSL 자동 변경 적용 본인의 블로그 웹서버는 아래 조합으로 서비스 중이다. CentOS 7 + APM + WordPress 이 기반으로 이미
How to replace the GBIC(SFP Module) during online on Linux Server
GBIC(SFP Module) 교체 방법 – Diagram +——————————————————+ | | | Server | | | +——————————————————+ | | | | | | | HBA 1 HBA 2 | | +————+ +————+ | | | | | | | | |
value of path fail policy on Linux
1. failback 값은 active 패스가 있는 priority가 높은 패스 그룹에 failback 하기 전 시간을 지정하는 작용을 합니다. 한개의 패스 그룹(2개 패스 이상)이 있어 크게 필요하지 않을것으로 판단됩니다. A value of time specifies failback delay to the highest priority path group
semaphore tuning values
Question) 베리타스 넷백업 마스터 서버에 대한 세마포어 값 조정을 위한 질문입니다. 현재 해당 서버는 BareMetal 이며 512G 메모리로 운영중입니다. 현재 마스터서버의 세마포어 값이 OS Default 값으로 다중의 백업 잡에 의한 프로세스들을 처리하기에 부족할 수 있다하여 베리타스에서는 권고값으로 변경을 권고하고 있습니다.
"Reserved Block" of XFS Filesystem
Q1) XFS 파일시스템도 EXT4 파일시스템처럼 기본적으로 Reserved Block 이 있나요? Q2) XFS 파일시스템은 데이터 단편화에 의한 성능 이슈가 없는지요? 아니면 EXT 파일시스템에 비해 상대적으로 덜한 것인지요? A1) XFS 파일시스템도 역시 5% (by default)를 reserved 하게 됩니다. 확인은 아래와 같은
파일시스템 df – use% 계산 방식 및 단편화
ext4 파일이스템의 사용률 계산에 대한 문의 Q1) EXT 파일시스템의 경우 단편화로 인한 성능 이슈로 기본적으로 5% Reserved Block을 가지고 가는데 Use% 계산에 영향을 미치는 것으로 보입니다. df 로 출력 값 중 Use% 어떠한 계산식에 근거하여 산출되는지 알고 싶습니다. Q2) 계산된
'vm.swappiness=1' on RHEL 6
FAQ Q1) Setting vm.swappiness=0 on RHEL 6.4 – 6.7 can cause OOM conditions. https://access.redhat.com/solutions/1149413 위 사례에 해당하는 현상이 발생하지 않기 위해서는 저희 측 서버(RHEL 6.7 – 2.6.32-573.el6.x86_64)의 경우에는 workaround로 vm.swappiness=0 이 아닌 vm.swappiness=1 설정을 하는 것이 맞을지요? A1)