ㄴ 기타

9월 5일 - 엔지니어 기본

깜자왕 2022. 9. 5. 11:08
반응형

엔지니어 기본

 

솔루션 엔지니어

-> 어떤 업무를 하는지, 업무의 범위

-> 고객이 필요로 하는 인프라 환경을 제공하기 위해 적절한 HW/SW를 조합해 설계/설치/유지보수를 수행

-> 유지보수 계약을 맺고 잘 작동되는지 상시 확인 및 요청대응

 

다양한 버그/오류들 내재되어 무조건 있음. 고객사에게 트러블슈팅 및 해결책 제안 -> 유지보수

 

엔지니어의 자세

- 고객사에게 제공하는 솔루션에 대한 정보 및 문제에 대한 공유 (내가 겪은 솔루션을 정리해 타 엔지니어에게 도움이 되도록 공유)

- 현재는 정보를 갖는다고 내 가치가 올라가진 않음. 빠른 정보 검색 및 습득이 중요

- 나만 아는 기술이 되어버리면 좋은 게 아님

 

- 고객에게 제공하는 기술에 대한 신뢰성(벤더 공식 자료, 산출물) 확보

- 우리회사의 기술이 아니므로 공식문서를 기반으로 해야함. 정확한 정보 전달 (A회사에서 이렇게 해결했더니 됐다가 아님)

- 공식문서를 기반으로 해결 못할 시 선임분들께 문의

- 버전의 앞 숫자가 바뀐다는 건 세계 트렌드에 맞춰 새로운 기술이 추가됨을 의미한다

 

- 내가 다루는 솔루션들에 대해 꾸준한 관심이 필수

- 현재는 vSphere에 대한 역량이 우선

 

- 빠른 IT 기술 트렌드 변화에 대해 맞춰 역량 개발

 

굿아 엔지니어 기술경험 공유

-> 황순혁 이사님이 팀즈에서 공유하고, 메일 업무보고(노랑 표) 참고 (가장 기본이 됨), 메일 업무보고 후 만약 시간이 되면 사내 공유폴더를 통해 여러 정보들 확인 가능(산출물)


가상화를 구축하기 위한 인프라 (서버, 네트워크, 스토리지)

 

설계를 위해 그림도 필요함

 

예전은 물리적인 여러 서버를 배치하고 각각에 맞는 용도로 사용했지만, 비용 및 공간제약이 발생

이를 해결하기 위해 가상화 이용

 

온프레미스 인프라 방식 - 데이터센터 & 서버실에서 인프라 직접 관리 (아직까지 80% 정도의 고객사는 이 방식 사용)

클라우드 인프라 방식 - 데이터센터의 인프라를 사용자에게 제공

-> 아직까진 퍼블릭에 서비스를 올리는 경향이 많지 않음

 

서버 시스템

- 사용자에게 네트워크를 통해 특정 서비스를 제공하는 컴퓨터 자원

- 서버 시스템에서 제공하는 애플리케이션에 따라 서버의 이름 명명

 

시스템 아키텍쳐에 따른 구분 -> UNIX / x86 -> 현재 대부분 시장은 x86 기반

시스템 구성 방식에 따른 구분 -> Rack / Blade

Blade -> 커다란 샤시안에 슬롯들이 있음. 이 슬롯들 안에 서버를 넣어 구축

-> Rack에 비해 서버의 크기가 줄어들음. 케이블링에 대해서도 통합할 수 있는 환경이 구성되어 있어 이점이 있음

 

고객의 서버 하드웨어 제조사를 사전파악해 여러 호환성 체크 후 고객사에게 모든 정보를 제공, 결정은 고객사가 하도록

 

*공통적으로 엔지니어끼리도 소통이 되어야 고객사 프로젝트를 진행할 수 있기 때문에 서버 뿐 아니라 스토리지/네트워크 등의 분야도 기본들은 알아야 한다

 

 

네트워크 시스템

- L2, L3, L4, Backbone

 

스토리지 시스템

- 인프라 구성 방식에 따라 DAS / NAS / SAN 형태로 구분

 

DAS - 서버 / 스토리지 직접 연결 -> 기본적으로 물리적인 제약때문에 잘 사용x -> 확장성 떨어짐

NAS - 네트워크를 통해 스토리지를 붙임 -> NFS(기본) / iSCSI

SAN - 광케이블 이용 -> 중간 SAN 스위치를 이용 -> 확장성 올림

 

이중화 / 고가용성

- SPOF(single point of failure) 상황을 방지하는 이중화, 서비스가 지속적으로 가동될 수 있도록 상태를 구성하는 고가용성

이중화

- 서비스 장애 발생 시 최소한의 downtime 보장 (HA)

- redundency -> 장치 및 인터페이스 등을 2개 구성 (HA와는 다름)