클러스터의 주요 병목 현상은 무엇입니까?

클러스터의 주요 병목 현상은 디스크입니다. 우리가 떼 작전에 직면했을 때 우리가 원하는 것은 즉시 그것을 읽는 것입니다. 하지만 빅데이터 앞에서 데이터를 읽으려면 디스크 IO가 필요합니다. 여기서 IO는 수도관으로 이해될 수 있습니다. 파이프라인이 더 크고 강력할수록 T 수준 데이터를 더 빨리 읽을 수 있습니다. 따라서 IO 품질은 클러스터의 데이터 처리에 직접적인 영향을 미칩니다.

클러스터의 병목 현상에 대해 많은 의견이 있으며 그 중 네트워크와 디스크 IO가 더 논란의 여지가 있습니다. 여기서 설명해야 할 것은 네트워크는 병목 현상이 아닌 희소 자원이라는 것입니다.

디스크 IO의 경우: (디스크 IO: 디스크 출력)

클러스터 작업에 직면할 때 우리가 원하는 것은 즉각적인 가독성입니다. 하지만 빅데이터 앞에서 데이터를 읽으려면 IO가 필요합니다. 여기서 IO는 수도관으로 이해될 수 있습니다. 파이프라인이 더 크고 강력할수록 T 수준 데이터를 더 빨리 읽을 수 있습니다. 따라서 IO 품질은 클러스터의 데이터 처리에 직접적인 영향을 미칩니다.

다음은 참고할 수 있는 몇 가지 예입니다.

사례 1

Alibaba Cloud를 사용한 이후로 세 가지 오류(1개, 2개, 3개)가 발생했습니다. 이 세 가지 오류는 모두 높은 디스크 IO와 관련이 있습니다.

zzk.cnblogs.com 인덱싱 서비스를 실행하는 클라우드에서 첫 번째 오류가 발생했습니다. 서버에서 Avg.Disk 읽기 대기열 길이가 200이 넘네요.

image.cnblogs.com 정적 파일을 실행하는 클라우드 서버에서 두 번째 오류가 발생했습니다. 큐 길이는 약 2입니다(추후 분석, 파일을 직접 읽고 응답하는 사진 사이트와 같은 응용 프로그램의 경우 디스크 읽기 큐 이 값에 도달하는 길이는 응답 속도에 큰 영향을 미칩니다.

3번째 오류는 데이터베이스 서비스를 실행하는 서버에서 발생했습니다. 길이가 4~5에 도달하면 많은 데이터베이스 쓰기 작업이 시간 초과됩니다.

(여기서는 "하드 디스크"와 "디스크"를 모두 언급합니다. 이렇게 정의합니다. 클라우드 서버에 보이는 하드 디스크를 디스크[가상 하드 디스크]라고 하고, 클러스터에 있는 물리적 하드 디스크를 하드 디스크)

이 세 번의 높은 디스크 IO는 우리 클라우드 서버의 애플리케이션으로 인해 발생한 것이 아닙니다. 가장 직접적인 증거는 클라우드 서비스를 다른 클러스터로 마이그레이션한 후 문제가 즉시 해결되었다는 것입니다. 즉, 클라우드 서버의 디스크 IO가 높은 이유는 위치한 클러스터의 하드 디스크 IO가 높습니다.

클러스터의 하드 디스크 IO는 클러스터에 있는 모든 클라우드 서버의 디스크 IO를 누적한 것입니다. 클러스터의 하드 디스크 IO가 높은 이유는 클러스터 내 일부 클라우드 서버의 디스크 IO가 너무 높기 때문입니다. 그리고 우리는 그 이후로 내 클라우드 서버의 애플리케이션에서 생성된 디스크 IO가 정상 범위 내에 있습니다. 문제는 다른 사용자의 클라우드 서버에서 너무 많은 디스크 IO를 생성하여 전체 클러스터 하드 디스크 IO가 높아져 우리에게 영향을 미친다는 것입니다.

다른 클라우드 서버로 인한 하드 디스크 IO 문제가 우리에게 영향을 미치는 이유는 무엇입니까? 문제의 근본 원인은 클러스터의 하드 디스크 IO가 클러스터의 모든 클라우드 서버에서 공유되고 있으며, 이러한 공유가 효과적으로 제한되거나 제한되지 않는다는 것입니다. 효과적으로 격리되면 모든 사람이 이 리소스를 놓고 경쟁하게 됩니다. 동시에 너무 많은 사람이 경쟁하면 대기열이 길어지게 됩니다.

그리고 각 클라우드 서버마다 얼마나 많은 클라우드 서버가 경쟁하고 있는지는 클라우드 서버 사용자 입장에서는 알 수 없습니다. 이 경쟁을 피할 수 있는 방법은 없습니다. 월드 엑스포 기간과 마찬가지로 아무리 일찍 일어나 줄을 서더라도 여전히 매우 긴 줄을 기다려야 합니다.

각 클라우드 서버에서 사용하는 하드 디스크 IO 리소스가 제한되거나 격리되면 다른 클라우드 서버에서 추가로 생성됩니다. 과도한 디스크 IO는 커뮤니티와 마찬가지로 클라우드 서버에 영향을 미치지 않습니다. 집을 직접 임대하면 100명이 다른 집에 거주하더라도 영향을 받지 않습니다.

CPU, 메모리, 대역폭, 하드 디스크 공간을

구입할 수는 있지만 진심으로 서비스를 제공하는 하드 디스크 IO는 구입할 수 없습니다. 이것은 현재 Alibaba를 설계할 때 고려되지 않은 중요한 문제입니다. 클라우드 가상화 플랫폼. Alibaba Cloud 기술 직원과 대화한 결과, 그들이 이 문제를 인식하고 있으며 이 문제가 가능한 한 빨리 해결될 수 있기를 바란다는 것을 알게 되었습니다.

-------------------------------------- ------------------------------------- -----------------------

사례 2

클라우드 컴퓨팅으로 가는 길- 마이그레이션 알리바바 클라우드 진입 후: 20130314 클라우드 서버 장애

먼저 모든 분들께 사과의 말씀을 드립니다. 이번 클라우드 서버 장애는 17시 30분경에 발견되어 18시 30분경에 정상화되어 모든 분들께 심려를 끼쳐드렸습니다. .용서해주세요!

오류의 원인은 클라우드 서버의 클러스터 부하가 너무 높고, 디스크 쓰기 성능이 급격히 떨어져서 많은 데이터베이스 쓰기 작업이 시간 초과되었기 때문이었습니다. 나중에 정상으로 돌아온 해결책은 클라우드 서버를 다른 클러스터로 마이그레이션하는 것이었습니다.

다음은 주요 실패 과정입니다.

오늘 오전 9시 15분경, 정원사가 이메일을 통해 정원에 접속할 때 502 Bad Gateway 오류가 발생했다고 신고했습니다.

알리바바에서 반환한 오류입니다. Tegine은 Alibaba에서 개발한 오픈 소스 웹 서버입니다. Alibaba Cloud에서 제공하는 로드 밸런싱 서비스는 Tegine 리버스 프록시를 통해 구현될 수 있을 것으로 추측됩니다.

이 오류 페이지는 로드 밸런싱의 클라우드 서버가 500 시리즈 오류와 같은 잘못된 응답을 반환했음을 로드 밸런서가 감지했음을 나타냅니다.

작업 지시를 통해 이 상황을 Alibaba Cloud에 보고했으며, 계속해서 관찰하라는 피드백을 받았습니다. 이는 사용자의 네트워크 회선에 일시적인 문제가 원인일 수 있습니다.

이 기간 동안 이 문제가 발생하지 않았고, 다른 사용자도 이 문제를 보고하지 않았으므로 계속 관찰하는 처리 방법도 승인했습니다.

(나중에 분석한 바에 따르면 502 Bad Gateway 오류는 클러스터의 일시적인 높은 부하로 인해 발생할 수 있습니다.)

오후 17시 20분쯤 저희도 502 Bad Gateway 오류가 발생했는데, 이는 오랫동안 지속되었습니다. 약 1-2분 . 아래 사진을 참고하세요:

문제가 발생하는 동안 두 개의 클라우드 서버에 빠르게 로그인하여 상황을 확인한 결과 동시 IIS 연결 수가 30배 이상으로 증가했으며 바이트 수는 Send/sec는 0이고 두 클라우드 서버 모두 상황은 동일합니다. 당시 우리는 두 클라우드 서버 자체에는 문제가 없어야 한다는 결론을 내렸습니다. 문제는 이들 서버와 데이터베이스 서버 간의 네트워크 통신에 있을 수 있습니다. 편지. 우리는 계속해서 작업 지시를 통해 이 상황을 Alibaba Cloud에 보고할 것입니다.

작업 지시서를 작성하자마자 블로그 백엔드에서 기사를 게시할 수 없다는 정원사로부터 전화를 받았습니다. 테스트하자마자 실제로 게시가 불가능했으며 데이터베이스 시간 초과 오류가 보고되었습니다. , 아래 사진과 같이

하지만 기존 글 열기 글 속도가 매우 빨라서 정상적으로 읽을 수는 있지만 쓰기에 문제가 있다는 뜻입니다. 빠르게 데이터베이스 서버에 로그인하여 성능 모니터를 통해 디스크 IO 상태를 확인해보세요 당연히 아래 그림과 같이 디스크 쓰기 성능에 문제가 있는 것입니다. Write Queue Length가 1을 초과하면 문제가 있음을 의미합니다. 이제 평균이 4~5에 도달했습니다. Alibaba Cloud 웹 사이트의 관리 콘솔에 들어가면 아래 그림과 같이 디스크 IO 문제가 더욱 분명해집니다.

Alibaba Cloud에 계속 피드백을 제공했는데, 제가 받은 피드백은 이것의 IOPS였습니다. 클라우드 서버가 너무 높습니다. 아래 그림을 참조하세요.

그래서 Alibaba Cloud 직원은 클라우드 서버를 다른 클러스터로 마이그레이션했고 문제는 즉시 해결되었습니다.

-------------------------------------- ------------------------------------- ----------------------------------------

사례 3

14시쯤: 17, 우리는 이 플래시를 보았습니다. 즉시 블로그 백그라운드 테스트에 들어가 제출 시 다음 오류가 발생하는 것을 확인합니다.

"Timeoutexpired. The timeout period elapsed before done of the Operation or the server is response."

이것은 데이터베이스 쓰기입니다. timeout.Error, 이 오류 메시지는 여전히 우리 마음 속에 남아 있습니다. 이전에 두 번(3월 14일과 4월 2일) 이런 일이 발생했는데, 둘 다 데이터베이스 서버가 위치한 클라우드 서버의 디스크 IO 문제로 인해 발생했습니다.

클라우드 서버에 가서 Windows 성능 모니터를 확인하고 로그 파일이 있는 디스크의 IO 모니터링 데이터 Avg.Disk Write Queue를 찾으세요. 평균 길이는 5 이상입니다. 성능 모니터에서 이 값의 세로 좌표에서 가장 높은 값은 1입니다. 값 5가 얼마나 높은지 상상할 수 있습니다. 성능 모니터의 그래프는 거의 직선입니다. 아래 그림을 참고하세요(가장 높은 값 실제로 20에 도달했는데 정말 무섭습니다.):

(로그 파일이 있는 높은 디스크 IO에 데이터베이스 쓰기 시간 초과가 표시되는 이유는 무엇입니까? 데이터베이스 복구 모드는 전체를 사용하기 때문에 데이터베이스에 대한 데이터 쓰기는 먼저 쓰기 작업은 로그에서 수행됩니다. )

이 문제는 3월 14일 발생한 디스크 IO 문제와 동일한 성능이므로 이번에도 클러스터의 높은 디스크 IO 부하로 인해 발생한다고 결론을 내렸습니다. 클라우드 서버가 위치해 있습니다.

14:19, 제목에 "긴급"을 추가하여 작업 주문을 제출했습니다.

14:23, Alibaba Cloud 고객 서비스는 우리가 제출한 문제를 확인 중이라고 답했습니다.

14:31; 클라우드 고객 서비스에서는 검사를 위해 관련 부서에 보고되었다고 답변했습니다.

14시 42분, 알리바바 클라우드 고객센터에서 더 이상의 소식이 없어 "단시간 내에 해결이 불가능할 경우 빠른 시일 내에 클러스터 마이그레이션을 진행하도록 하겠습니다"라고 답변드렸습니다. (이 문제는 클러스터를 통해 해결되었습니다.) 3월 14일, Alibaba Cloud 기술 직원 높은 클러스터 부하로 인해 발생하는 디스크 IO 문제의 경우 현재 유일한 해결책은 클러스터 마이그레이션이라고 합니다.)

14:47, Alibaba Cloud 고객 서비스에서는 그렇다고만 답변했습니다.

14:59, 아직 소식이 없어 불안합니다(40분이 지났는데 설명이 없습니다). 작업 지시서에서 "클러스터를 먼저 마이그레이션해도 될까요?"라고 말했습니다. Alibaba Cloud 고객 서비스로부터 클러스터의 다른 클라우드 서버가 차지하는 디스크가 IO 높이로 인해 우리에게 영향을 미쳤으며 이를 처리하고 있다는 전화를 받았습니다. . .

잠시 후 Alibaba Cloud 고객 서비스에서 다시 전화를 걸어 서버 디스크 쓰기가 중단된 원인이 클라우드 서버의 시스템이나 애플리케이션일 수 있다고 말했습니다. (이러한 고려사항은 이때까지 클러스터 부하가 떨어졌기 때문일 수 있지만, 우리 클라우드 서버 디스크 IO는 여전히 높습니다.)

15시 23분경에 데이터베이스 서버를 다시 시작했지만 문제는 남아있었습니다.

15:30, Alibaba Cloud 고객 서비스에서 마침내 클러스터 마이그레이션을 결정했습니다. (작업 주문 제출부터 클러스터 마이그레이션 결정까지 1시간 10분 소요)

15:45, 클러스터 마이그레이션이 완료되었습니다(마지막 마이그레이션은 5분도 채 걸리지 않았는데, 이번에는 15분이 걸렸는데, 이는 알리바바 클라우드 고객 서비스에 따르면 클러스터 마이그레이션에 필요한 가장 긴 시간이기도 합니다.

마이그레이션 후 디스크 IO(Avg.Disk Write Queue)가 어리둥절했습니다. 길이) 아직 너무 높아요!

이번 클러스터 마이그레이션으로 지난번처럼 문제를 즉시 해결할 수 없는 이유는 무엇인가요? 두 가지 이유가 있을 수 있습니다.

1. 마이그레이션 후에도 클러스터 디스크 IO 로드가 여전히 높습니다. 클라우드 서버의 디스크 IO가 높은 파티션에는 데이터베이스 로그 파일이 포함되어 있습니다. 이 기간 동안 로그 쓰기 작업이 평소보다 더 자주 발생하고(하지만 급증은 거의 불가능함) 모든 로그 파일이 동일한 파티션에 있을 수 있습니다. 영역, 클라우드 서버 디스크 IO의 일정 한도를 초과하여 디스크 IO 성능이 급격하게 저하됨(클라우드 컴퓨팅으로의 경로를 기준으로 볼 때 가능성은 상대적으로 높음 - Alibaba Cloud 진입 후: Images.cnblogs.com 해결) 응답 속도가 느린 이상한 문제). 이전에는 물리적 서버를 사용할 때는 로그 파일이 동일한 파티션에 배치되어 이러한 문제가 발생하지 않았지만 이제 클라우드 서버의 디스크 IO 기능은 물리적 서버의 성능과 비교할 수 없습니다. 비율 및 디스크 IO는 클러스터의 다른 클라우드 서버와 경쟁하게 됩니다(자세한 내용은 클라우드 컴퓨팅으로의 길 참조 - Alibaba Cloud로 이동한 후: 문제의 근본 - 그녀의 "사람"을 구매하지만 그녀의 "마음"을 구매하지 않음) " ).

어떤 이유에서든 문제를 해결할 수 있는 최후의 수단은 단 하나뿐입니다. 로그 파일이 있는 디스크 파티션의 IO 압력을 줄이는 것입니다.

스트레스를 줄이는 방법은 무엇인가요? "Alibaba Cloud로 이동한 후의 경험" 기사의 "전체 디스크 IO 성능을 향상시키는 작은 방법"에 따라 디스크 공간을 추가로 구입한 다음 블로그 콘텐츠를 저장하는 데이터베이스 CNBlogsText(대형 텍스트 데이터)를 작성합니다. 디스크 IO(고압) 로그 파일이 별도의 디스크 파티션에 저장됩니다.

SQL Server에서는 한 디스크 파티션에서 다른 디스크 파티션으로 데이터베이스 로그 파일을 이동하는 작업을 온라인으로 수행할 수 없습니다. 먼저 데이터베이스를 분리한 다음 로그 파일을 대상 파티션에 복사한 다음 연결 중에 데이터베이스를 연결하고 로그 파일 위치를 새 경로로 변경해야 합니다.

그래서 우리는 선택의 여지 없이 CNBlogsText 데이터베이스에서 분리 작업을 수행하고 연결을 끊기로 결정했습니다. 분리 프로세스 중에 예기치 않게 비극이 발생했으며 오류는 다음과 같습니다.

트랜잭션 (프로세스 ID 124)가 다른 프로세스와의 잠금 리소스에서 교착 상태에 빠졌습니다. 교착상태 피해자로 선택되었습니다. 트랜잭션을 다시 실행하세요.

재 분리 프로세스 중에 교착 상태가 발생하여 "희생"되었습니다. 혼란스러운 점은 연결이 끊어지지 않은 경우 어떻게 교착 상태가 계속 발생할 수 있다는 것입니다. 떨어질 수 있음 분리 작업이 공식적으로 시작되기 전에 연결이 끊어지는 동안 데이터베이스 쓰기 작업도 발생합니다. 왜 왜 분리를 희생해야 합니까? 비양심적이다.

분리 실패 후 CNBlogsText 데이터베이스는 단일 사용자 상태가 됩니다. 계속 분리, 동일한 오류, 동일한 "희생".

그래서 SQL Server 서비스를 다시 시작했습니다. 다시 시작하면 CNBlogsText 데이터베이스 상태가 복구 중으로 변경됩니다.

시간이 16시 45분이 되었습니다.

이런 회복 상태를 본 적이 없어서 어떻게 대처해야할지 모르겠고 감히 성급하게 행동하지도 않습니다.

잠시 후 SQL Server의 데이터베이스 목록을 새로 고쳤더니 CNBlogsText 데이터베이스에 이전 단일 사용자 상태가 표시되었습니다. (SQL Server를 다시 시작하면 자동으로 먼저 In Recovery 상태로 진입한 다음 Single User 상태로 진입하는 것으로 나타났습니다.)

단일 사용자 상태 문제와 관련하여 Alibaba Cloud 작업 주문에서 Alibaba Cloud 고객 서비스에 문의했습니다. 고객 서비스팀에서 데이터베이스 엔지니어에게 연락하여 다음과 같은 내용을 받았습니다. 이 작업을 수행하라는 제안이 있습니다: alter Database $db_name SET multi_user

따라서 다음 SQL을 실행하십시오:

exec sp_dboption 'CNBlogsText', N'single', N'false'

오류 메시지가 나타납니다:

Database 'CNBlogsText' is already open and can only have one user at a time.

단일 사용자 상태가 동일하게 유지됩니다. 이 오류는 데이터베이스가 지속적으로 입력 작업을 작성하고 단일 사용자 상태에서 허용되는 유일한 데이터베이스 연결만 선점하기 때문에 발생할 수 있습니다.

（更新：后来从阿里云DBA那学习到解决这个问题的方法：

select spid  from sys.sysprocesses where dbid=DB_ID('dbname');
--得到当前占用数据库的进程id
kill [spid]
go
alter login [username] disable --禁用新的访问
go
use cnblogstext
go
alter database cnblogstext set multi_user with rollback immediate
go

）
当时的情形下，我们不够冷静，急着想完成detach操作。觉得屏蔽CNBlogsText数据库的所有写入操作可能需要禁止这台服务器的所有数据库连接，这样会影响整站的正常访问，所以没从这个角度下手。
这时时间已经到了17:08。
我们也准备了最最后一招，假如实在detach不了，假如日志文件也出了问题，我们可以通过数据文件恢复这个数据库。这个场景我们遇到过，也实际成功操作过，详见：SQL Server 2005数据库日志文件损坏的情况下如何恢复数据库。所需的SQL语句如下：

use master 
alter database dbname set emergency 
declare @databasename varchar(255) 
set @databasename='dbname' 
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态 
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 
dbcc checkdb(@databasename,REPAIR_REBUILD) 
exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态

即使最最后一招也失败了，我们在另外一台云服务器上有备份，在异地也有备份，都有办法恢复，只不过需要的恢复时间更长一些。

想到这些，内心平静了一些，认识到当前最重要的是抛开内疚、紧张、着急，冷静面对。

我们在工单中继续咨询阿里云客服，阿里云客服联系了数据库工程师，让我们加一下这位工程师的阿里旺旺。

我们的电脑上没装阿里旺旺，于是打算自己再试试，如果还是解决不了，再求助阿里云的数据库工程师。

在网上找了一个方法：SET DEADLOCK_PRIORITY NORMAL（来源），没有效果。

时间已经到了17:38。

这时，我们冷静地分析一下：detach时，因为死锁“被牺牲”；从单用户改为多用户时，提示“Database 'CNBlogsText' is already open and can only have one user at a time.”。可能都是因为程序中不断地对这个数据库有写入操作。试试修改一下程序，看看能不能屏蔽所有对这个数据库的写入操作，然后再将数据库恢复为多 用户状态。

修改好程序，18:00之后进行了更新。没想到更新之后，将单用户改为多用户的SQL就能执行了：

exec sp_dboption 'CNBlogsText', N'single', N'false'

于是，Single User状态消失，CNBlogsText数据库恢复了正常状态，然后尝试detach，一次成功。

接着将日志文件复制到新购的磁盘分区中，以新的日志路径attach数据库。attach成功之后，CNBlogsText数据库恢复正常，博客后台可以正常发布博文，CNBlogsText数据库日志文件所在分区的磁盘IO（单独的磁盘分区）也正常。问题就这么解决了。

当全部恢复正常，如释重负的时候，时间已经到了18:35。

原以为可以用更多的内存弥补云服务器磁盘IO性能低的不足。但万万没想到，云服务器的硬伤不是在磁盘IO性能低，而是在磁盘IO不稳定。

更多相关知识，请访问：PHP中文网！

위 내용은 클러스터의 주요 병목 현상은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!