Date: Wed, 03 Aug 2005 22:43:39 +0400 From: Anton Nikiforov <anton@nikiforov.ru> To: freebsd-cluster@freebsd.org Subject: Re: DRBD-like something for FreeBSD Message-ID: <42F1105B.5040507@nikiforov.ru> In-Reply-To: <42EE7813.8020902@centtech.com> References: <42EE559A.3080000@nikiforov.ru> <42EE7813.8020902@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms080906050304020905040404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric Anderson wrote: > Anton Nikiforov wrote: > >> Dear ALL, >> I'm running a few clusters with Linux, but do not like it ;) and would >> like to move to FreeBSD. >> I know about vrrpd and pfsync and other solutions, i know how to run >> Oracle or Postfix or PostgreSQL under such a configuration. but the >> only thing i cannot find is something like DRBD device that is working >> pretty cool and stable under linux (it is mirroring raw partitions >> from one node to other/s). >> Could someone please direct me to the link or list where i can read >> something about? > > > GEOM Gate and GEOM mirror are probably what you want. Check out ggated, > ggatec and geom_mirror. > > Eric Thanks for the replay, Eric, Please correct if i'm wrong. You suggest to make two devices one is local daX device and the other is ggated/gagatec device and build a mirror set on them using geom_mirror module and gmirror utility? That is pretty cool idea, but what i should do in case main (ggated) system crash? I'm still reading and investigating this issue, and will test it as soon as i'll get to PCs/Servers to test, but as for now i do not see the way to promote second node as prymary in case of real prymary crashed. Or i should test it with vrrpd (for example) and restart secondary as ggated instead of being ggatec? Did not clear yet. If you have the solution or an idea - could you please drop me a line? algorythm looks the following for me: We have two computers: stage 0 (up and running claster) 1. da0 is exported via ggated over the network. This computer runing postgresql (for example) that storing data on da0. 2. da1 is being imported over network via ggatec as da1. Local da0 and remote da1 are mirrored via ggated/geom_mirror.ko and there is no service activity on this device. just a mirroring of data. stage 1 (slave failed) 1. working as before 2. down Requests to update remote data failed. There should be no problem. stage 2 (slave is coming up) 1. working as before 2. booting and starting to mirror date from the master in case secondary goes down and up again there are no troubles. it just boots itself in the stage0 config. that is it stage 3 (master is down) 1. down 2. should consider master is down and stop ggatec, then start ggated and export the da0. Then mount da0 and start PostgreSQL. stage 4 (master coming up) 1. Should understand it is not the master anymore and start ggatec and mirror remote data to the local drive. 2. running as a master. with services moved/started at stage 3 Here troubles begins. When bouth become synchronized the service that was running on this disk shoul be moved from 2 to 1. to do that i'll have to restart services in stage 0. But how? using vrrpd? or some other utility? How can i understand that the system is ready to get the Postgresql back to 1 and stop it on 2? stage 5 (bouth down, master coming up first) 1. Starting as master, exactly as it did before stage 0 2. Starting as in stage 1 stage 6 (bouth down, slave is coming up first) 1. Have to determine which was doun first and in case 1 was - start as the slave and vise versa - in case it was down last - should start as master. 2. Have to determine which was doun first and in case 2 was - start as the slave and vise versa - in case it was down last - should start as master. This is main confuse. Maybe i did not read mutch, but it is not clear for me, how to inderstand which drive contain the last data? Best regards, Anton Nikiforov > > > > --------------ms080906050304020905040404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKDCC AuEwggJKoAMCAQICAw6AYzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDE2MTEwMzExWhcNMDYwNDE2MTEwMzEx WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJh bnRvbkBuaWtpZm9yb3YucnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDp45jI HORB4RVcbIIDMttb19fW9gb9dIX4CVBbCZSPmX+gpsYUCswB/wcqnF98LoSTIYxiY/hUrENH 5lObA+oEazWWmZQR5MQIgZViQ3H7vJ1KpaQ8tR7atUsCMudFb9Wu4jYgvFbjhYLO0cOFOfhr n99ucG5qpsXwriIbDYLT20xFvsbCk/zlMwPsIfxell+EM87MglUH5uym8LtcWVvfZgzYuNN0 1lJXF4Qs17X3y3XELuuRowdQGZQ6nNM2StTePuOL6J3piVERqhscLIpM9rjfH6nV8HM1+BW3 trgt5rWqzSfFlvxk6MF6cvz06xnE6Yw4FV63lrRzaiwm914/AgMBAAGjPzA9MA4GA1UdDwEB /wQEAwIHgDAdBgNVHREEFjAUgRJhbnRvbkBuaWtpZm9yb3YucnUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQASvk2h3CLH4S3NOw9yRfEdpHruWxov2mQvsV8qZKwjG8/661ze FmsQhAS18+6hCgK84qNrCINydH06Y5jsAGmwS8r9m+xOPxDKiehmOSsOpSVShzIfWdRx5Ni1 uFvPwH9L6czsOlw0PAQnYEv0jVbel6SA5MUWHwJ8liIGxkhi3jCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNV BAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQ CjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk 16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAG AQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNm rGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0 niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggJEMIICQAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIDDoBjMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODAzMTg0MzM5WjAjBgkqhkiG9w0BCQQxFgQUcc+m 13VDe+2HSpghdmZcJAkJZukwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEggEA1XLtfjHZMguOS0pkae+b89JkjDnPjR17Dw2WlbftapXb95dI4RabbhBz hLDf04ldfvYDgTTU/KWcZ+VQP7iDyuGkbvjqZSOBKYvycuEmo2pkS3EfYvuM/zpu6k7RQDaH 1g3z6u8D4HcUBi/7FDkjO5Jihik+xpmSMUZauTF7R+lN2DxSAjRPnu8+TWiUYK83Q+oJLOsx blMzqmjSGI82rMVVNTmKRiYfHDjCuRkUQ97XCe6tzogdSk4rUkFvvyVwpSBuauAxB7YDCVXV 6kUXKXDd8RS33aG6dmznh1ltw3YrEW1zhv4kawuDBRqNirwEjqERLSPl6lVSzdrwbCUvkgAA AAAAAA== --------------ms080906050304020905040404--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F1105B.5040507>