Hi Amir, You might also do a ping and a traceroute between the machines and see what kind of latency you're getting, just in case it's a timeout issue with Hazelcast.
-Colin On Tuesday, March 24, 2015 at 11:32:21 AM UTC-5, Amir Khawaja wrote: > > Hi Colin, > > Thank you for the prompt response. > > I'm a little confused as you say "the US West node will not come online >> telling me that the database is not yet online. At that point, I kill the >> process and then eventually the database comes online." > > Do you mean you kill the database process and then restart it and then it >> starts communicating? > > > Yes. I kill the database process on the cluster node where the OrientDB is > not coming online. > > Can you see on each machine when Hazelcast 'sees' all the members? Are >> all the members showing up? > > > Yes. I see the databases are talking to each other as the IP address of > the nodes show up in the log of each database server. > > I will try setting hotAlignment to false and report my results on this > thread. > > Amir. > > > On Tuesday, March 24, 2015 at 11:25:16 AM UTC-5, Colin wrote: >> >> Hi Amir, >> >> Is it consistently a problem between the same machines not seeing each >> other? >> >> I'm a little confused as you say "the US West node will not come online >> telling me that the database is not yet online. At that point, I kill the >> process and then eventually the database comes online." >> >> Do you mean you kill the database process and then restart it and then it >> starts communicating? >> >> In your distributed json file, try setting "hotAlignment" to false. >> >> Can you see on each machine when Hazelcast 'sees' all the members? Are >> all the members showing up? >> >> -Colin >> >> Orient Technologies >> >> The Company behind OrientDB >> >> On Tuesday, March 24, 2015 at 11:19:05 AM UTC-5, Amir Khawaja wrote: >>> >>> Greetings, everyone. Has anyone had much success running an OrientDB >>> 2.0.5 cluster in Azure? I created a cluster in Windows Azure with 4 nodes >>> using CentOS 7 and OrientDB Community 2.0.4 -- 2 nodes in US East2 and 2 >>> nodes in US West. There is a Site-to-Site VPN connection between the two >>> regions in Azure and data is flowing between machines across the network. I >>> have three databases that I have currently deployed and testing. I find >>> that many times the synchronization between databases does not occur. For >>> instance, if I startup the first node in US East2 and once that comes >>> online, fire up the second node in US West, the US West node will not come >>> online telling me that the database is not yet online. At that point, I >>> kill the process and then eventually the database comes online. I even have >>> to go so far as to delete the databases in the database path folder. I do >>> this a few times and eventually the server may startup. Sometimes, I will >>> have three of the four nodes working and the fourth just refuses to come >>> online. >>> >>> The VM size selected for each node in the cluster is a D4 (4 cores, 28GB >>> RAM). This should be more than sufficient to handle most loads. Surely, I >>> must be missing something as this is not acceptable production behavior. >>> For reference, I am pasting the hazelcast.xml and >>> default-distributed-db-config.json files here in hopes that someone has >>> some pointers for me. >>> >>> *** hazelcast.xml *** >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> <!-- ~ Copyright (c) 2008-2012, Hazel Bilisim Ltd. All Rights Reserved. ~ >>> ~ Licensed under the Apache License, Version 2.0 (the "License"); ~ you >>> may >>> not use this file except in compliance with the License. ~ You may obtain >>> a copy of the License at ~ ~ http://www.apache.org/licenses/LICENSE-2.0 >>> ~ >>> ~ Unless required by applicable law or agreed to in writing, software ~ >>> distributed >>> under the License is distributed on an "AS IS" BASIS, ~ WITHOUT >>> WARRANTIES >>> OR CONDITIONS OF ANY KIND, either express or implied. ~ See the License >>> for >>> the specific language governing permissions and ~ limitations under the >>> License. --> >>> >>> <hazelcast >>> xsi:schemaLocation="http://www.hazelcast.com/schema/config >>> hazelcast-config-3.0.xsd" >>> xmlns="http://www.hazelcast.com/schema/config"; xmlns:xsi=" >>> http://www.w3.org/2001/XMLSchema-instance";> >>> <group> >>> <name>[name]</name> >>> <password>[password]</password> >>> </group> >>> <network> >>> <port auto-increment="true">2434</port> >>> <join> >>> <multicast enabled="false"> >>> <multicast-group>235.1.1.1</multicast-group> >>> <multicast-port>2434</multicast-port> >>> </multicast> >>> <tcp-ip enabled="true"> >>> <member>10.0.0.4</member> >>> <member>10.0.0.5</member> >>> <member>10.1.0.4</member> >>> <member>10.1.0.5</member> >>> </tcp-ip> >>> </join> >>> </network> >>> <executor-service> >>> <pool-size>16</pool-size> >>> </executor-service> >>> </hazelcast> >>> >>> >>> *** default-distributed-db-config.json *** >>> >>> { >>> "autoDeploy": true, >>> "hotAlignment": true, >>> "executionMode": "synchronous", >>> "readQuorum": 1, >>> "writeQuorum": 3, >>> "failureAvailableNodesLessQuorum": false, >>> "readYourWrites": true, >>> "clusters": { >>> "internal": { >>> }, >>> "index": { >>> }, >>> "*": { >>> "servers" : [ "<NEW_NODE>" ] >>> } >>> } >>> } >>> >>> Thank you for any assistance you can offer. >>> >>> Amir. >>> >> -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
