“오늘날”우리는 항상 OS 드라이브 (Windows)를 데이터 드라이브에서 분리했습니다. Linux 세계에서는 익숙하지 않지만 최선의 구성으로 정의되고 사용되는 볼륨이 더 많다는 것을 알고 있습니다.
이제 서버 스토리지가 SAN (디스크 리소스가 많은 개별 운영 체제 및 응용 프로그램에서 공유되는)에있을 가능성이 높으므로 OS 및 데이터 파티션이 볼륨 수준에서 분리되는 것이 더 중요합니까?
당신의 생각은 무엇입니까?
답변
OS와 데이터를 스토리지 단위로 분리하기위한 세 가지 주요 드라이버가 있습니다.
- 우주 . ErikA가 지적했듯이, 실제로 OS 볼륨에 공간이 부족한 것을 원하지 않습니다. 모든 종류의 나쁜 일이 일어날 수 있습니다. 이 두 가지 성장 방법을 분리
- I / O 액세스 요구 사항 . OS 볼륨에서 사용되는 I / O 유형은 일반적으로 데이터 볼륨에서 사용되는 유형과 많이 다릅니다. I / O 유형을 별도로 유지하는 것은 여러 수준에서 매우 좋은 생각입니다.
- 스토리지 이식성 . 서버 OS를 업그레이드 할 때가되면 OS 볼륨을 늘리고 모든 데이터를 유지할 수 있습니다. 또는 SAN 또는 VM 환경에서는 데이터 볼륨을 새로 설치된 새로운 서버로 옮기고 업그레이드 시간을 절약 할 수 있습니다.
또한 일부 운영 체제 (Windows 중 일부)는 OS 볼륨 크기를 조정하는 데 너무 친절하지 않으므로 일반적으로 서버를 포맷 할 때 평생 필요한만큼 많은 양을 제공해야합니다. 이것을 서버 수명 기간 동안 여러 번 크기를 조정할 수있는 데이터 볼륨과 대조하십시오. OS와 Datavvolume 자체가 동일한 실제 스토리지에 수용되는 완전히 가상화 된 환경에서도 OS 볼륨의 크기를 조정할 수없는 것이 큰 장애가 될 수 있습니다. Windows 2008+는 현재 C : \ 드라이브에 30GB를 권장합니다. Server 2003에서 사용하던 10GB와는 거리가 멀었습니다. 이것은 많은 Windows 관리자들이 2003 년에서 2008 년으로 전환 할 때 많은 어려움을 겪을 것입니다.
답변
그렇습니다. OS와 데이터를 구분하는 것이 가장 확실합니다. 공유 파티션으로 파티션이 가득 차서 OS 패치가 불가능하고 (다양한 이유로 인해) 파티션을 확장 할 수없는 등의 시간과 시간을 다시 보았습니다.
IMO는 두 개의 파티션을 관리하는 데 드는 오버 헤드는 제공된 격리 비용을 지불하는 데 적은 비용입니다.
언급 한 SAN 지원 시스템과 관련하여 OS 파티션을 채우는 데이터로부터 여전히 보호되지는 않습니다. 완전히 가상화 된 스토리지를 사용하면 OS와 데이터가 별도의 스핀들에서 작동하는지 걱정할 필요가 없습니다.
답변
나는 그것이 당신이 시스템으로 무엇을하고 있는지에 달려 있다고 말합니다. 운영 체제를 다시 설치해야 할 경우 모든 데이터를 별도의 파티션에 저장하여 번거 로움을 덜 수 있습니다. 그렇지 않으면 나는 더 이상 필요성을 보지 못한다. 내 두 센트
답변
일반적으로 기본 OS 공간 (예 : C :)을 데이터 (D :)에서 분리하는 것이 좋은 생각이지만 로그 파일 (L :)을위한 작은 파티션을 만들어 작은 공간을 확보하는 것이 좋습니다. 보다 안전하고 일부 유형의 서비스 거부 공격을 방지합니다.
Linux는 파일 시스템이 사용하는 물리적 디스크 또는 가상 파티션 수에 관계없이 하나의 루트 디렉토리 아래에 계층 적으로 유지된다는 점에서 매우 좋습니다. 디스크를 확실히 분할하지만 데이터와 OS 분리를 위해 반드시 필요한 것은 아닙니다 (두 개가 어쨌든 혼합되기 때문에).
나는 볼 것이다 :
- 디스크를 채우고 다른 디렉토리에 공간 문제를 일으키는 하위 디렉토리 (예 : / home 및 / var / log 파티션)
- 디렉토리 구조의 다른 부분에 성능상의 이유로 다른 파일 시스템이 필요한지 여부 (예 : 안정성을위한 XFS, 만능 사용을위한 Ext3 등)
- 향후 확장해야 할 디렉토리-단순히 디렉토리의 이름을 바꾸고, 새로운 디스크 공간 세트를 디렉토리 위치로 분할하고 마운트하고, 데이터를 이전에서 새로운 것으로 복사 할 수 있기 때문에 파티셔닝에 적합한 후보입니다. 위치.
답변
역사적 리눅스 (실제로 유닉스에서) 파티셔닝 권장 사항은 부분적으로 (네트워크로 연결된) 메인 프레임 서버 OS의 기원에 기인합니다. 이는 결국 하드웨어의 상대적 신뢰성에 영향을받은 것으로 의심됩니다. 예를 들어 저장 영역이 많이 마모되어 로그와 임시 데이터가 분리 되었으나 손실 된 경우 큰 문제가되지 않았습니다.
데스크탑 시스템을 구축하는 경우 데이터 / 비 데이터 / 스왑 분할로 이동합니다. 심각한 중단을 예상하는 서버를 구축하지 않는 한 별도의 / usr / local 및 / var / tmp와 같은 항목은 공간 할당 문제가됩니다.
답변
100Gb의 데이터 (너무 많은 pr0n 친구 :)가 있고 OS를 다시 설치해야하거나 Windows 기록과 함께 정기적으로 다시 설치하여 내장을 제거해야한다고 말하고 싶습니다. cruft)는 C 파티션에있는 것보다 그대로 유지하는 매우 간단한 문제입니다.
그러나 Windows가 특히 C 드라이브의 디렉토리에 모든 종류의 물건을 채우는 것을 좋아하는 문제가 있다고 말하고 싶습니다 .’users ‘디렉토리뿐만 아니라 모든 앱 데이터와 다양한 비트와 조각이 붙어 있습니다. ProgramData에서도 마찬가지입니다.
또한 또 다른 요인이 있습니다. 실제로 큰 문제 (다시 pr0n)와는 별도로 연속 백업을 수행하는 많은 온라인 백업 도구 (또는 로컬 백업 유틸리티)가 있습니다. 이러한 경우 백업 위치에서 데이터를 쉽게 복원 할 수 있으므로 데이터를 분리하는 것이 우선 순위가 아닙니다.
개인적으로 데이터 + OS를 분리하려고합니다. 또한 앱을 다른 파티션에 배치하려고 시도하여 OS 백업이 훨씬 작습니다.
답변
나는 다른 생각의 학교에 대한 악마의 옹호자가 될 것입니다.
성능상의 이유로 공급 업체는 OS 파티션이 “드문 드문”하지 않고 전체 OS 파티션을 미리 할당하도록 권장합니다. 그 결과 SAN 드라이브에서 10Gb ~ 20Gb (또는 그 이상)의 사용되지 않은 공간이 생깁니다.
이는 단일 VM에는 적합하지만 각각 10 ~ 20Gb의 공백 오버 헤드가있는 여러 “성능이 중요한”서버가있을 수 있습니다. 우리 환경에서이 공백은 SAN 디스크의 20 %를 차지했습니다. SAN 디스크를 채우는 데 한계가 있다는 것을 명심하십시오 (그러나 그것은 또 다른 이야기입니다).
경영진은 선택했다
1) SAN에서 20 %의 낭비 된 공간을 흡수합니다.이 공간은 “공백”의 다른 요구 사항 외에도 발생할 수있는 “전체 디스크”시나리오를 격리합니다.
2) 모든 것을 C : \ 드라이브에 넣고 응용 프로그램 로그로 인해 드라이브가 채워질 위험이 있습니다.
그들은 무엇을 했습니까?
Windows 2008R2가 호스트 OS의 C : \ 드라이브를 동적으로 확장 할 수 있고, 드라이브가 가득 차면 드라이브를 확장 할 수 있다는 점을 고려할 때 관리 비용을 절감하고 SCOM과 같은 모니터링 도구에 다시 투자했습니다.
이제 C : \ 드라이브 충전에 대한 단순한 보호 이상의 기능을 제공하지만 다른 문제가 발생하기 전에이를 해결하기 위해보다 완벽한 시스템 모니터링 기능을 갖추고 있습니다.
